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ABSTRACT 

The User Equipment (UE) Global Positioning Sysoem (GPS) 
Configuration Control structures, procedures and infcrmarion 
system up to March 1983 is critiqued. Our objective was to 
explore rhe exisring configuration management plans in terms 
of documentation, with specific emphasis on the feasibility 
cf the configuration control plans for the Navy unique and 
DoD ccmmon items. Our conclusion is that the GPS 

Configuration Control Structure is fundamentally sound. 
However, a major problem of integrating the various facets 
of configuration control management exists. To correct this 
deficiency, the GPS Program must now obtain interservice and 
intraservice written agreements of Configuration Control 
Responsibility to further specify and clarify each service's 
Configuration Control boundaries. 
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I. INTRODUCTION 



A. BACKGROUND 

Thare is general agreement rhat military usars would 
benefit from global deploymant of a precise navigation 
system. Precise positioning and navigation (POS/NAV) needs 
for the Department of Dafanse (DOD) have traditionally bean 
satisfisd by a multitude of spacialized equipments respon- 
sible to particular mission requirements. The result has 
been a proliferation of POS/NAV systems producing an aggra- 
gate of system facilities and airborne, shipboard, and 
ground user tarminals with varying degrees of accuracy and 
capabilities. Deployment of the Global Positioning System 
(GPS) will reverse this trend while providing accurate 
POS/NAV for all military users. 

Generally speaking, the conduct of military operations 
requires that forces involved accurately know their posi- 
tion, velocity, and time. The missions assigned to the 
respective services generate a broad spectrum of unique yet 
in many cases, similar navigation requirements. The degree 
to which these requirements are satisfied directly affects 
the outcome of military ventures, particularly in multi-unit 
and joint service operations. 

Global navigation requirements as stated by the 

Assistant Secretary of Defease For To mmunicat ions , Command, 

Control, and Intelligence are: 

We need a system which can provide accurate navigation 
anywhere on the globe, one which is independent of ground 
stations, since we cannot be assured of the cooperation of 
countries enroute or in the vicinity of a crisis. We need 
a system which is accurate enough to serve as an 
instrument landing system, sines we cannot be certain 
of the facilities which will be available at the airfields 
in a given crisis area. We need a system in which 
security is inherent in the design and does not compromise 
the existence or oosition of the user. [Ref, 1] 
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Th 5 NAVSTAfi GPS is a spacr-basad radio positioning and 
navigation system that will provide extremely accurate 
three-dimensional position (to within 16 meters spherical 
error of probability), velocity (to within 0.05 meters/ 
second) and system time (to wirhin 55 nanoseconds) to 
suitably equipped users anywhere on or near (within 500 
miles) the earth. The GPS consists of three major segments: 
Space System Segment, Control System Segment, and User 
System Segment. [Ref. 2] 

The operational GPS Space System Segment deploys six 
planes of satellites containing three satellites each, this 
deployment will provide adequate satellite coverage for 
continuous and worldwide three dimensional positioning, 
navigation and velocity determination. Each satellite tran- 
smits a composite signal at two L-band frequencies 
consisting of a precision navigational signal (P CODE) and a 
coarse acquisition (C/A CODE) navigational signal. [Ref. 3] 

The Control System Segment consists of four widely sepa- 
rated Monitor Stations that are located in 0. S. territory 
or U. s. controlled territory. The stations passively track 
all satellites in view, and accumulate ranging data from the 
navigational signals. Ranging information is processed at a 
Master Control Station, located in the Continental United 
States, for use in satellite orbit determination and syste- 
matic error correction. 

The User Equipment Segment consists of three user sets 
that will be used in numerous host vehicles. The thesis is 
focused on this segment. 

Using the navigation signals from each of four satel- 
lites, the user receiver/processor (RPU) converts the 

pseudcranges and pseudorange rates to three-dimensional 

position and velocity, and system time. The position solu- 
tion is in earth-centered coordinates, which can be 

converted to any coordinate frame or units of measure the 
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user requires. To accomplish the navigation function, pseu- 
dorange and delta pseudorange measurements are used to 
update a running estimate of the user's position. [Ref. 4] 

B. ACQUISITION APPROACH 

The acquisition approach for the GPS, recommended by the 
Defense Systems Acquisition Review Council (DSARC) , is a 
step-wise, des ign- to-cost development and test program 
leading in successive phases to an operational GPS. Each 
phase is designed to build and expand on the previous phase 
in an integrated and cohesive manner. Phase 1, Concept 
Development, concentrated on validation of design concepts 
and developing a functional baseline through Development 
Test and Evaluation (DTSE) of user equipment. Phase 2, 
Demonstration/ Validation, will complete the DTSE and 
Initial Operational Test and Evaluation (lOTSE) of user 
equipment. Finally during Phase 3, Production/Development , 
the full GPS capability will be achieved. [Ref. 5] 

Phase 1 encompassed the first of two dssign-build-test- 
design cycles to determine preferrred user equipment 
configurations and validate the conceptual life cycle cost 
models in the design-tc-cost process. The purpose of this 
approach was to reduce overall program risk, to reduce 
projected user equipment design and life-cycle costs through 
encouraging innovative designs, to increase industry compet- 
ition by broadening the industrial base, and to full/ 
investigate the potential classes of user equipment. Strong 
emphasis was placed early in these contracts on low develop- 
ment costs through the use of modular hardware and software 
designs, while total life cycle costs were minimized through 
the use of common modules across various host vehicle cate- 
gories, wherever possible. [Ref. 6] 
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User equipmen-t activities ia Phase 2 are primarly . 

concerned with development: and testing of prototypes of user 
equipment. Two contractors are developing the basic set 
architecture for a family of user equipment hardware to be 
used in all classes of host vehicles. This approach 

provides commonality across all classes of user equipment 
designed by each contractor and should achieve the desired 
cost benefits in Phase 3. The commonality designed into the 
user equipment covers both areas of hardware and software. 

During Phase 3, the user equipment will move into full 
scale production. The family of user equipments which best 
meets the user's needs in terms of performance and life- 
cycle-cost will be selected for production. 

The user equipments to be produced, as determined by 
individual user requirements, will be procured in large lot 
buys. Eventually, 20-30,000 sets could be deployed by the 
U.S. Military with a like number deployed by our allies. 
[Ref. 7] 

In summary, the three phased development and deployment 
of the NAVSTAR GPS is an evolutionary process. Each step 
provides extensive legacy value for the next step. 
Throughout this process, system level testing will be accom- 
plished in order tc insure optimum system operation and 
emphasis will continue to be placed on obtaining information 
on the utilization of all types of user equipment for new 
military applications and tactics. 

C. PORPOSB/TIME FRAME OF THE RESEARCH 

The objective of this thesis project is to explore the 
existing configuration management planning in terms of docu- 
mentation, with specific emphasis on the feasibility of the 
configuration control plans for the Mavy unique items and 
the DcD common items. A review of existing DoD, Navy and 
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Air Fores irsrructions and directives was undertaken for a 
comparison base to evaluate the 3PS configuration control 
management plans. A further study of existing literature on 
the subject of configuration control of both hardware and 
software, in conjunction with visits to the Joint Program 
Office (JPO) in Los Angeles, Ca. and Warner Rebins Air 
Logistics Center (WR-ALC) in Warner Robins, Ga. completed 
our research. 

The research was conducted during the September 1982 to 
March 1S83 time frame. The GPS program was in full scale 
development and preparing for DSARC III. Our intention is 
to present a critique of the configuration control manage- 
ment plans as they existed during the research time frame. 
Our interpretations of the documents, including our under- 
standing of the statements and comments gathered through 
interviews and telephone conversations, are the basis for 
the conclusions presented in this thesis. The acquisition 
and configuration management plans are dynamic; therefore, 
the analysis and conclusions are the result of the configu- 
ration control management plans as seen by the researchers, 
up to the March 1983 time frame. 

D. ASSUMPTIONS 

A basic assumption concerning the configuration control 
management of the GPS User Equipment (UE) should be noted. 
The assumption is the determination of which configuration- 
items (CIS) and computer program configuration items (CPCIs) 
are DcD common or Navy unique. The Navy unique items for 
this discussion are considered to be the Flexible .Modular 
Interface (FMI) and its associated CPCIs. Antennas could 
fall into the Navy unique category under certain conditions. 
This thesis was limited to the discussion of the FMI and its 
computer programs as the pivotal unique item. It was 
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considered by the researchers that if the configuration 
contrcl management plans could support the FMI it would also 
be able to support any antennas associated with the GPS UE 
program. 

The DoD common items considered in this project were the 
Control Display Unit (CDU) , some antennas and antenna elec- 
tronics and the Receiver/ Processor Unit (RPU) . The RPU 
became the area of most concern due to its being the Cl with 
embedded CPCIs and the unit that directly interfaces with 
the FMI. The RPU is in very simple terms a micro-computer 
consisting cf approximately 80% software. The RPU in opera- 
tional form has the software etched on computer chips making 
it firmware. 

The user equipment segment of the GPS is compos<=d cf 
uniquely conFigured ensembles of equipment, called Sets, as 
well as test instrumentation and Peculiar Support Equipment 
(PSE) . Each set consists of the hardware and software 
necessary to convert the GPS navigation signals into timing 
data, positioning data, navigation data, and control/display 
signals, as required. The scope of this thesis project is 
limited to and focused on the configuration control manage- 
ment plans for the Sets. 

The remainder of this thesis deals exclusively with the 
user equipment segment. It is limited to the configuration 
contrcl plans for the Navy unique and the DoD common user 
equipment. 
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II. CO NFK ORATION CONTROL LITERARY RESEARCH 

A. CONFIGORATION HANAGEHENT/CONFIGORATION CONTROL 

Ccnf iguration Management (CM) accepts the fact that 
changes occur during a project's life cycle. Configuration 
Management tries to manage these changes and accept only the 
changes that offer a significant benefit ~o the government. 

As a project moves through concsp* exploration, demons- 
tration and validation, full scale development then into 
production and deployment (phases 0,1,2 and 3) its configu- 
ration identification is continually modified. Accordingly 
the configuration of a product is developed during concept 
exploration, determined during demonstration and validation, 
established during full scale development and maintained 
during production and deployment. [Ref. 8] 

In a buyer-seller relationship, particularly in the 
aerospace marketplace where the buyer is usually purchasing 
not only the end product but its design and development as 
well, the point of departure or "baseline” between each 
phase has significance. Each baseline represents a point of 
decision by the buyer or negotiation between the buyer and 
seller, cr both. The buyer must have some measure of super- 
vision over the seller's activities to assure that ; (A) he 

has significant basis for making the basic critical deci- 
sions, such as continuation, cancellation or modification of 
a project; (B) He is getting the product contracted for at 
all times; and (C) The product will be compatible with the 
ether configuration items in his complement of equipment or 
associated project interfaces. [Ref. 9] 
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The overall objective of configuration management is to 
deliver to the buyer, both functionally and physically, the 
intended product as specified by the contract drawings and 
specifications. The product configuration is identified to 
the lowest level to assure consistent performance, quality 
and reliability. 

Configuration management allows for the integrity and 
continuity of technical and cost decisions related to the 
product's producibility, performance, operation and maintai- 
nance are recorded and controlled by Project Managers. The 
process of configuration management encompasses the special- 
ties of configuration control, configuration identification 
and configuration accounting. 

The goal of these operations is to assure that the 
delivered Cl or CPCI meets Form, Fit and Function require- 
ments. Configuration refers to a complete description of 
the physical and functional characteristics of a product. 
Configuration also applies to technical descriptions 
required to build, test, operate and repair a CI/CPCI. 
[Hef. 10] The major facets of configuration management are 
shown in Fig. 2. 1. 

Configuration Control involves the systematic evalua- 
tion, coordination and approval or disapproval of proposed 
changes to the design and construction of a CI/CPCI whose 
configuration has been formally approved internally by the 
company or by the buyer or both. [Bef. 11] 

Configuration Identification refers to the technical 
identification that identifies and describes the approved 
product configuration throughout the design, development, 
test and production tasks. It also applies to the identifi- 
cation of changes and to product markings. 

Configuration Accounting is the recording and reporting 
of CI/CPCI descriptions and all departures planned or made 
from the CI/CPCI through the comparisons of authorized 
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Figure 2.1 CONFIGORATIOH HANAGEaENT INTERR ELATIONSBIPS. 
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design data and the fabricated and tes-ed configuration cf 
the CI/CFCI. [Ref. 12] 

Samaras and Czerwinski stare in their bock, 

"Fundamentals of Configuration flanagemenr" , the key features 
in the configuration management process. They are: 

1. Early and complete definition of Configuration 
Management goals, scope and procedures. 

2. Speed in evaluating and processing changes. 

3. Accurate identification and accounting of changes. 

4. Complete descriptions of changes. 

5. Clcse coordination among key elements of the project 



team . 

6. Cooperative and responsive buyer. 

7. Minimum labor requir aments. 

Tc achieve effective configuration management the 
configuration manager must be independent of quality assu- 
rance, production, engineering, etc. The separation is 
necessary tc achieve unbiased control and to prevent any 
conflicts of interest. 

To assist the Configuration Manager, a Configuration 
Contrcl Beard (CCB) is established. The CCB includes repre- 
sentatives of production, engineering, contracting, 

purchasing, quality assurance, maintainanilit y and data 
processing. The CCB is responsible for complete change 
evaluation, change planning, change incorporation and as a 
result is usually the final authority on proposed changes. 

A typical Program Off ice, and where Configuration 

Management functions within that office, is shown in Figure 
2.2. The GPS configuration management structure is detailed 
further in chapters 4 and 5. 
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Figure 2.2 COHFIGOR&T ION aANAGENENT COORDINATION. 
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developed. Software has evolved from being the computer's 
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set cf instractions to BEING the system. Software row 
contains the description of what the total system is 
supposed to do and the hardware is the means through which 
the instructions are carried out. 

The result is that software is a dominant and crucial 
piece cf the computer system. Software clearly warrants at 
least the same degree of development, discipline, quality 
assurance and configuration management as the hardware. The 
problem we face today is that many managers see software as 
esoteric and mysterious, causing greater anxiety among their 
numbers than the more familiar hardware. 

Proof of the managerial inattention to software surfaced 
in 1975 as a result of the Johns Hopkins University Applied 
Physics Laboratory (APL) and the aiTHE Corporation studies 
of the DCD weapons systems software management. 

The MITHE Corporation revealed that software problems 
stemmed from the fact that a lack of discipline and engi- 
neering rigor applied consistently to the software 
acquisition activities. Some specific areas identified in 
the study that contributed to software cost and schedule 
growth were: [Ref. 13] 

1. Poorly formulated initial software requirements. 

2. Changing requirements and requirements growth during 
the development phase. 

3. Improper use cf standards and guidance documents in 
specific procurements. 

The Applied Physics Laboratory study resulted in 17 
recommendations all addressed to different topics. Three 
that pertain to configuration management were: [Ref. 14] 

1. Major computer software involved in weapons systems 
should be designated "configuration items" and be 
deliverable during full scale development. 

2. Use tcp down design, specifically, the use of modular 
software architecture. 
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The conrractor should be required to apply a higcer 
set of engineering prac’:ic 2 s to the detailed design 
and programming phase of development. This includes 
a set of standards covering program srructure, size, 
control, interface, formal conventions on data base 
management and demonstration that the standards are 
reinforced in practice. 

An important aspect that should be understood is rhat 
every post delivery change to software is not a maintenance 
action but a change to the design of the delivered package. 
Software programs do not fail as hardware systems do. 
Zeroes and ones do net wear out. Software systems have no 
need for classical maint enanace. The inevirable results of 
these modifications are unnecessary ''dewn" time of the 
system and unwarranted additional costs. 

The Program Manager’s job is not easy when dealing with 
software. The Program Manager must realize software and 
hardware are both configuration items. He must determine 
how, when, and by whom changes to delivered software can be 
made . 

The Program Manager must decide how much Preplanned 
Product Improvement will prevail after the CPCI is deliv- 
ered. Changes after program delivery must be provisioned 
since these changes result in partial or total revision of 
the original software. Consideration must be given to docu- 
mentation, configuration control, distribution of the 
changes, facilities used, scope of the changes, change sche- 
dules, effected activities, etc. Overall the Program 
Manager must truly appreciate the nature of the software and 
any modifications to it. 

The pcint that software and hardware are configuration 
items can not be over emphasized. In the case of GPS, 
changes to software and hardware can be placed into two 
classifications (lAM APR 8 00- 14 and MIL-STD-483) . These 
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changes are referred to as Class I (changes that affecr rhe 
current configuration) or Class II (changes not affecr ing 
Class I criteria such as document rypos, misspelling, clari- 
fying notices, etc.) , [Ref. 15] 

Requirements for documentation vary depending on the 
phase and complexity of each CI/CPCI and the change itself. 
Basically, documentation falls into three categories, 

according to NAVMATINST 4130.13 (draft); [Ref. 16] 

1. The documentation forwarded to the change installing 
activities as a package with the implementing 
directive/order involved to properly install the 
change. 

2. The documentation required by the technical, 
training, maintenanace and supply management organi- 
zations to properly control and support each change. 

3. The documentation required by the user activities to 
properly operate and maintain the CI/CPCI after the 
change is installed. 

In the case of software, the "NAVSTAR Global Positioning 
System Operational/Support Configuration Management 
Procedures" (draft) [Ref. 17], specifically addresses 
computer program configuration item documentation. CPCI 
documentation comprises two disinct areas: 

1. Documentation, including flow charts, engineering 
data (design, test, interface specifications) etc., 
required in the development or testing of a computer 
program. This documentation will be identified with 
a CPIN related to the basic CPCI. 

2. Documentation that instructs the user so that he can 
operate or load the computer programs. This type of 
documentation will be as a technical order. 

NAVMATINSI 4 130. IE (draft) does address the contractor's 
responsibilities which is consistent with item 1 above. 
NAVMATIllST 4130. IB says," the contractor is responsible for 
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preparing the detailed production drawings and computer 
software, manufacturing the change hardware and firmware and 
assembling the technical documentation, hardware, firmware 
and computer software into a retrofit kit to meet the 
delivery schedule established by the CCBD. " 

The overall differences between software and hardware 
configuration control documentation is not significant. All 
data delivered under a hardware or software contract is 
defined in the Contract Data Requirement List (CDRL) , DD 
Form 1423. The point is that software is a configuration 
item and requires the Configuration Management emphasis that 
hardware now receives. The GPS management realize this fact 
which is witnessed in the User Equipment configuration 
control structure. All computer program changes must 
proceed through two more configuration sub-boards than hard- 
ware related changes. Software in the GPS structure is 
scrutinized by the User Equipment Computer Program Screening 
Panel (UE CPSP) and the User Equipment Computer Program 
Configuration Sub Board (UE CPCSB) before it proceeds to the 
User Equipment Joint Configuration Control Board (UE JCCB) . 
The fact that software changes are design changes not 
maintenance actions requires the additional analysis offered 
by these additional configuration sub-boards. 

The GPS hardware/software configuration control struc- 
ture is managerally sound in design. The ultimate success 
of the program rests with the involved agencies who must 
realistically adhere to the provided policies and procedures 
of the Operational/Systems Configuration Management 
Procedures. 
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EXISTING GUIDELINES FOR CONFIGURATION CONTROL 



The NAVSTAR Global Positioning Sysrem Operar ior.al 
Support Configuration Management Procedures (0/S CMP) is 
just one publication xhe GPS configuration control structure 
must follow. Basically, the O/S CMP expands on the proce- 
dures outlined in the GPS Joint Services Support Management 
Plan (JSSMP) , Integrated Logistics Support Plan (ILSP) and 
the Computer Resources Integrated Support Plan (CRISP) . 
Overall the GPS configuration control structure must abide 
by; Hil-Std-480A (Configuration Control- Engineering 
Changes, Deviations and Waivers), Mil-std-481 (Configuration 
Control Engineering-Changes, Deviations and Waivers short 
form) and MIL-STD-483 (USAF Configuration Management 
Practices, Systems, Equipment, Munitions and Computer 

Programs) . 

Besides following the GPS regulations, the Navy must act 
in accordance with their own instructions and regulations. 
Specifically they are; NAVMATINST 4130.1 (DOD Configuration 
Management Procedures) and YEL 30-122 (Navy Computer 
Resources Management Plan (the Navy annex to the GPS CRISP) . 
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III. BASELINE FOR GPS/OSER EQOIPMENT 



A. GENERIC BASELINE 

The phase 3 GPS Osar Equipment will be comprised of 
several integral components, each of which will be desig- 
nated fcx usage on multiple platforms. These ccmmon 
components are referred to as Line Replaceable Units (LRU) , 
which, in turn, are composed of a set of common hardware 
replaceable modules and chassis components known as Shop 
Hepacsabls Units (SHU) . 

This approach is consistent with the overall strategy of 
minimizing Life Cycle Cost (LCC) by minimizing the number of 
platform unique elements, through the use of common modules, 
while satisfying the varying host vehicle unique require- 
ments. The integration of GPS UE onto Navy platforms will 
be achieved by selecting the appropriate combination of LRUs 
necessary to meet the individual platform requirements. 
[Ref. 18] 

The GPS system configuration management is managed 
through a series of time sequenced events known as base- 
lines. The foundation of a CM system “Exists in baseline 
management defined as the application of technical and 
administrative direction to designate and control the docu- 
ments which formally identify and establish the 
configuration identification of a CPCI or Cl at specified 
times during its Life Cycle i. e. , functional, allocated, and 
product baselines. 

Configuration identification is the current approved or 
conditionally approved technical documentation for a 
configuration item as set forth in specifications, drawings, 
and associated lists and documents. At any time in the life 
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cycle, the previously established baseline, together with 
approved changes, constitutes the current configuration 
identification of the system equipment. The identification 
of the GFS CIs/C?CIs is the basis for configuration control. 
The required configuration of the CI/CPCI is identified at 
this time by its development specifications. The achieved 
configuration will be identified by its product specifica- 
tion, which cannot be fully addressed until receipt of the 
GPS production specifications, drawings, and software docu- 
mentation targeted for DSARC III in FY 84. Therefore; the 
configuration control management structure has been planned 
using a generic baseline. This puts the necessary pieces in- 
place and will require only minor modification once the 
product baseline is finalized. 

The following provides a general description of the GPS 
UE at the LSU level, (major CIs) 



B. GPS LBOS 

^ • Antenna /A.ntenna Electr oni cs; The antenna and antenna 
electronics are separate LRUs. There are two generic 
types of antennas available for use as part of the 
UE, they are: 

a) Fixed Reception Pattern Antenna (FRPA) 

b) Contrclled Reception Pattern Antenna (CRPA) 

The FRPA is a simple omni-directional antenna with a 
deep null at the horizon. The CRPA is a multiple element 
array antenna with "steerable nulls" that has a similar 
receiving pattern to the FRPA under ambient jamming and Low 
Level Radio Frequency Interference (5FI) conditions. 
Additionaly, these CRPA antennas can sense jamming energy 
arriving from a specific direction and quickly adapt their 
receiving patterns to create nulls in those directions. The 
number of jamming sources that can be nulled is dependent on 
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the number of antenna slemenrs. The operation of the C5FA 
is self-contained and does not require any host vehicle 
inf ormaticn or interaction. 

2. Control Dis play U nit (C^) : The GPS Control Display 

Unit (CDU) provides the operator with the capability 
to control the UE , input data, and observe US gener- 
ated outputs. The GPS CDU contains operating 
controls, a data entry keyboard, and alphanumeric 
displays. The CDU will not be required when integra- 
tion of the Set is in a platform that has an existing 
CDU that can he utilized for GPS. 

2- Flexibl e Mo dular I nterf ace (FMI) : -he Flexible 

Modular Interface (PMI) will perform the interfacing 
function between the RPU and the user platform. The 
FMI will provide the GPS UE with the capability of 
interfacing with analog and digital avionics equip- 
ment and may contain a microprocessor for data 
manipulation where required. The FMI for each plat- 
form will be designed to meet the unique requirements 
of that particular platform. These unique designs 
will be based on the strategy of utilizing replace- 
able components common to all FMIs. This functional 
partitioning approach will allow for commonality in 
the use of the other LRUs across many Navy applica- 
tions while supporting platform unique requirements 
in the platform unique FMIs. 

• Rgce ive r Proce sso r U nit (RPU) : The RPU performs the 

signal and data processing. Three variations, each a 
separate LRU, make up the RPU family: 

a) High dynamic, fast signal acquisition (5 
channel) -for high performance aircraft and subma- 
rines 

b) Medium dynamic (2 channel) -for surface ships, 
helicopters, and medium performance aircraft 
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c) M anp a cic/ Vehicular (1 channel) -for infantry and 

vehicular cperations. 

Each of the RPUs shall perform the following functions: 

i) Receive and amplify signals transmitted by 
all visible satellites 

ii) Select and acquire signals from the four 
desired satellites 

iii) Track the acquired navigation signals (four 
simultaneously for rhe 5 channel, four 
sequentially for the 1 and 2 channel RPUs) 

iv) Extract information contained in the 

received satellite data 

V) Measure the signal propagation error 

vi) Provide resistance to jamming 

vii) Compute position, velocity, and time 

viii) Generate self test signals for UE fault 
isolation 

ix) Provide additional functions as required by 
platform configuration and mission. 

C. GPS DB CaPABILITl OPTIONS 

A major variable in determing the specific LRUs 

required, the overall GPS UE procurement, and individual 
platform installation is the extent to which the GPS UE is 
integrated within the host vehicle. This in turn has impli- 
caticns regarding the existing platform capabilities which 
GPS will enhance, or the new capabilities it will provide to 
the platform. The proposed hierarchy of GPS UE capability 
options available to the platforms are: 

Sta nd Alone: This option provides stand alone GPS 

position and velocity data to the user. The CDU is 
the sole source of information entry and display. 
The baseline equipment required consists of: 
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a) Anxen na/antsnn a alec-ronics (FRPA) 

b) Rsceivsr/prccesso r unit (1 channsl) 

c) Ccntrol/display unit 

• A rea Nav ioa ticn and Instrumen t Landing ; This option 
provides the capability to perform enrcute waypoint 
navigation in which waypoints are either preset or 
manually entered. In addition, instrument landing 
approach capabilities will be provided to determine 
deviation from course and glidepath as well as range 
and bearing to waypoints. The highly accurate GPS 
three dimensional position data could be used for 
non-precision instrument approaches to any airfield 
whose coordinates are known, including uninst rumen ted 
and temporary airfields. The baseline equipment 
required consists of: 

a) Antenna/antenna electronics (FRPA) 

b) Receiver/procssso r unit (2 or 5 channel) 

c) Flexible modular interface 

d) Ccntrol/display unit 

3. A lignme nt and Calib r at ion ; This option provides the 

capability of utilizing the GPS QE to update the 
platform cn-bcard Inertial Navigation System (INS) or 
other navigational aids. Also the other navigation 
sensors on-board can be used to update or verify GPS 
information. The baseline equipment required 

consists of; 

a) Antenna/antenna electronics (FRPA) 

b) Receiver/processor unit (2 or 5 channel) 

c) Flexible modular interface 

d) Ccntrol/display unit 

4. C cicgute r Update: This option provides the capability 

of utilizing the GPS OE navigation data to update the 
platform’s central or weapons computer. This capa- 
bility will enhance the functions of the systems 
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interfaced to these computers. The baseline equip- 
ment required consists of: 

a) Antenna/antenna electronics (FRPA) 

b) Receiver/processo r unit (2 or 5 channel) 

c) Flexible modular interface 

d) Ccntrol/display unit 

5* A nti- Ja m Enhancemen t ; This option provides the capa- 
bility of enhancing the anti-jamming capabilities in 
the GPS UE, there-by providing accurate position, 
velocity and time data in a hostile environment. 
Iirplement ation of this option could provide the plat- 
form with an anti-jam capability improvement between 
10 to 30 decibels [Ref. 19]. The baseline equipment 
required consists of ; 

a) Antenna/antenna electronics (CEPA) 

b) Receiver/ processor unit (2 or 5 channel) 

c) Flexible modular interface 

d) Ccntrol/display unit 

D. CCMPOTEH PROGRAMMING 

Computer programs for the GPS UE shall be designed in 
accordance with the following requirements: [Ref. 20] 

1. Each computer program error allocation when combined 
with the related hardware error allocation, shall not 
degrade the naviganional accuracy. 

2. Computer programs rhat provide navigation and timing 

daxa shall be designed to provide a graceful degrada- 
tion of accuracy as measurement data becomes 

unavailable or unreliable. Separate degraded-mode 
programs shall nor be utilized to provide this capa- 
bilixy. 

3. Computer programs shall be designed in a modular 
fashion to allow for maximum comparer program ccmmcn- 



29 



ality among all Sets and localize the impact of 
changes . 



4. Assembly language may only be used to implemsnn func- 
tions which cannot be coded efficiently in a 
high-level program language. 

5. All computer programs and corresponding documentation 
shall be written in a self-consistent and uniform 
notation . 

6. The Set executive computer programs shall be parti- 
tioned to distinctly isolate the set-unique 
exectutive control logic. The remaining general- 
purpose executive modules shall be as common as 
possible among all-sets. 

7. All computer programs within all the user ssgment 
sets shall utilize a common machine-language instruc- 
tion set. 

8. All computer programs within all the user segment 
sets shall be written in a single high-level program- 
ming language. 

9. Microcode and firmware shall be considered as soft- 
ware for definition purposes. 

The configuration Control Management Plan for DoD common 
and Navy Unique Cl and CPCI at the presenr time is based on 
the allocated baseline. Configuration Control will become a 
management of the product baseline after DSASC III. The 
considerations of baseline management are; 

1. Determine the need for a change. 

2. Prepare the change justification package. 

3. Conduct in-depth impact analysis. 

4. Review proposed changes with subsequent approval/ 
disapproval. 

5. Update approved change material 

6. Incorporate approved changes in Cl/C?CIs and its 
documenta tion . 
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Adherence to well defined procedures is the key elsraent in 
controlling and documenting changes to baselines. The 
configuration control plan is an attempt to define and 
establish these procedures. 
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A. DOD CONFIGOEATION CONTROL 

Configuration control is the systsmaric evaluation, 
coordination, approval, disapproval and impleaenraricn of 
approved changes to any baseline [Ref. 21]. Formal control 
of the configuration of a system or configuration irem/ 
computer program configuration irem (CI/CPCI) begins with 
the establishment of the firsr baseline and continues 
throughout the life cycle 

The objectives cf configuration control are to attain 
and maintain: [Ref. 22] 

1. An optimum degree of design and development latitude 
while introducing controls at the appropriate time, 
degree and depth during each phase of the life cycle 
of the Cl. 

2. Efficient processing and implementation of conrigura- 
ticn changes. 

3. Complete, accurate and timely documentation of the 
Cl's configuration consistent with total program 
needs. 

U. The required level of operational readiness, support- 
ability, interchangeability and interoperability 
through standardization and control cf design and 
change proliferation. 

5. Monitor life cycle cost effects of ECPs. 

Government configuration control is governed by 
DOD-STD-480 or MIL-STD-481, as appropriate. These standard- 
ization documents help identify the full impact of proposed 
changes to established configuration baselines and their 
subsequent current configuration identification. 
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Conzrol of all changes is a coordinated process of 
documentation, justification, systematic evaluation, deci- 
sion, release, implementation, reporting and mcnitcring 
between the office of primary responsibility (OPR) and the 
contractor for as long as the contractor is involved with 
the program. The OPR, during development and transition, is 
the JFO and the OPR becomes the JSSao after PMRT in ?Y 87. 

Proposed changes may be initiated by the OPR, the 
contractor or any activity that has an interest in the Cl. 
Activities outside of the OPR must submit changes to the OPR 
for consideration. The OPR's control over proposed changes 
is limited to those that have an affect on the current 
configuration identification of the Cl. The method for 
proposing changes, the documentation which describes the Cl 
and the related criteria which limits the OPR’s control are 
clearly defined in the contract requirements. 

All change proposal initiators must establish the basic 
factors of ; the description of the change, need for the 
change and the ccaditions of accomplishment capability (i.e. 
change accomplishment location, capability requirements for 
personnel and the time schedule) . The change initiator is 
responsible by the contract to establish the basic factors, 
determine the applicable criteria with supporting data and 
evaluate the criteria and data. 

Change proposals that do not offer significant benefit 
to the government are cancelled. Necessary or beneficial 
changes are those which; correct errors or deficiencies, 
resolve non-availability of parts and components, effect 
substantial life cycle cost savings, prevent stoppage or 
slippage in schedules, effect advancements in technology and 
any change that changes the mission element need. [Ref. 23] 

The OPR is responsible for establishing priorities and 
time spans for change proposal processing, based on the 

nature and relative urgency of the change. The proposed 
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priority is assigned by the initiator and stands unless the 
OPR has a valid reason for changing it. The OPR establishes 
detailed operating procedures, configuration status 
accounting records and other appropriate progress techniques 
necessary for timely processing of the change proposal. The 
OPR controls the processing of changes to avoid any unneces- 
sary delays which could prevent timely incorporation of 
changes during production, result in increased acquisition 
costs or deny DOD activities benefits from the change. The 
OPR can withold a change proposal's "production cut-in" for 
subsequent, rather than current, production lot to fulfill 
the requirement of giving the contractor sufficient notifi- 
cation in order to plan and perform turn around and recyclic 
engineering and production actions. 

The OPR controls the flow of change proposals through 
use of a "log" that is used to establish realistic targets 
for each proposal and provides the basis for program manage- 
ment evaluation as to the expeditious flow and status of 
each change. 

Tc provide for proper change proposal coordination, 
evaluation, processing, approval, disapproval and implemen- 
taticn cognizant DOD components establish a Configuration 
Control Board (CC3) . The CCB is the official agency to act 
on all changes. 

The CCB is composed of chartered representatives from 
all affected fields such as engineering, contracting, 
quality assurance, etc. Each representative presents his 
official position, based on his specialty, to the CCB. The 
CCB chairman, usually the Program Manager (PM) , maicas the 
final decision on all changes which are documented as CCB 
Directives (CCBD) or CCB Requests (CCBR) . The CCBD/CCBR's 
contain each CCB member's opinion, the implementation need 
date, the implementation schedule, contractual methods and 
identity of responsible activities. 
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All change evaluations take into account the relative 
merits of production cut-in and inventory retrofitting 
versus operating and supporting multi- configurations of the 
Cl. The impact of not making the change at all is always 
considered as an alternative. 

Changes beyond the scops of the CCB’s authority such as 
changes tc the program’s production schedule, missicn 
element need or program cost, require Office cf the 
Secretary of Defense (OSD) or DOD component approval, 

B. GPS CONFIGOHATION CONTROL 
1 • Ma~jcr Ag enci es 

The major agencies for GPS are: [Ref, 24] 

2-) O ffice Of Primary Responsibili ty (OPR) : The OPR 

for the operational/support configuration manage- 
ment procedures is the GPS Joint Services System 
Management Office (JSSMO) , after PMRT scheduled 
for FY 87, All proposed changes to the 
opera ticna 1/suppo rt configuration management 
procedures are submitted from the respective 
service command to the GPS JSSMO for final action. 
S erv ices Involved : The prime GPS users are the 

Air Force, Army, Navy, Marines, NATO and Defense 
Mapping Agency (DMA). User equipment (UE) test 
host vehicles include the USAF B-52 bomber and 
F-16A fighter; the Navy SSN-700 submarine, CV-59 
aircraft carrier and the A-6E attack aircraft; the 
Army UH-60 helicopter, M-60 tank and the soldrer 
himself (manpack 1 channel version). DMA and NATO 
test host vehicles will be identified at a later 
date. 

Contra cto r s; During Phase One (Demonstration and 

Validation) of the overall GPS program schedule 
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fcur ccatractors were selscred for UE deveiopaient 
during Phase II-A . Two contractors were salecced 
from these four for UE full scale development 
during Phase II-B: Magnavox and Roclcwe ll-Collins. 

E xec utive Servic e : DOD single manager policies 

direct nha services to centralize management and 
configuration control when multi-service resources 
are involved. As a result, the Air Force has been 
designated the Executive Service (single manager) 
for the GPS program and is responsible for the 
centralized management and configuration control 
of GPS hardware and software systems. 

The prime focal points for GPS are: [Ref. 25] 

1. Headquarters USAF; Provides management of GPS 
computer resources and ensures policies and proce- 
dures are consistent with applicable regulations and 
directives. 

2. Air Force Systems Command (AFSC) : Responsible for the 
development, acquisition, transfer and turnover of 
the GPS system. The responsibility has been dele- 
gated to the Space Division (AFSC/SD) and AFSC/SD has 
formed a Joint Program Office (J?0) to manage GPS 
multi-service involvement. 

3. GPS Joint Program Office (JPO) : The JPO has full 

management responsibilities prior to Program 
Management Responsibility Turnover (PMRT) . The JPO 
is the GPS System Manager (SM) up to the PMRT date, 
for the overall program. 

4. Air Force Logistics Command (AFLC) : AFLC implements 

all applicable instructions, regulations and direc- 
tives after PMRT and AFSC turnover, for DoD common UE 
items. AFLC has designated Warner Robins Air 
Logistics Center (WR-ALC) as the post-PKRT Systems 
Manager (SM) . Because GPS is a joint service 
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prcgraiB, the Navy and Army will have representatives 
at WR-ALC. 

C. GPS CONFIGORATION CONTROL RESPONSIBILITIES PRIOR 

TO/AFTER PMRT 

The objective of PMRT is to accomplish an orderly# 
timely and efficient transfer of overall Program Management 
Responsibility (PHR) at the earliest practicable date during 
the Production and Deployment Phase (Phase 3) . This is 
scheduled for FY 87. 

The Transfer Working Group (TWG) , established by the 
Program Manager# develops the schedule# coordinates the 
transfer and fabricates an overall transfer plan for the 
program. 

PMRT planning for joint service programs justifies the 
interrelationships and functional responsibilities of the 
executive and supporting services that become effective at 
the PMRT date. Therefore; after PMRT the Army and the Navy 
will report to the JSSMO vice the JPO. The USAF# as stated 
earlier# is the GPS Executive Service. 

Prior to PMRT# the JPO has configuration management 
responsibilities for the entire GPS program. The GPS JPO 
has developed and implemented a cost effective configuration 
management program by utilizing the contractor’s internal 
configuration management practices. The JSSMO begins moni- 
toring the configuration management at the beginning of 
Phase III and stops monitoring after PMRT when it assumes 
total program configuration management responsibility. 

The Transition Phase begins when the JPO reponsibility 
is gradually turned over to the JSSMO and continues to the 
PMRT. The GPS JPO Joint Configuration Control Board (JCCB) 
retains final approval for all configuration changes during 
the Transition Period. The configuration management func- 
tion continues to be administered by the GPS JPO with 
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increased participation from the support commands and user 
organizations until the PMRT date when all GPS system case- 
lines and related documentation are finalized then 
transferred to the JSSMO WR-ALC. 

After PMRT the JSSMO at MR-ALC has full joint service 
authority and responsibility for configuration management. 
The JSSMO has configuration control of every GPS unit except 
for the Flexible Modular Interface (FMI) and its internal 
software which is unique to a single host vehicle. In this 
case the FMI is managed by the host vehicle System 
Manager (SM) or Program Manager (PM). 

The Joint Service system Manager (JSSM) establishes the 
GPS Joint Configuration Control Board (JCCB) at Warner 
Robins Air Logistics Center (WR-ALC) . The GPS JCCB is 
tasked with controlling the configuration for the entire GPS 
hardware and software systems except for the host vehicle 
unique FMI units mentioned above. The JCCB is the regula- 
tory body for the subordinate configuration control boards 
shown in Figure 4.1. 

The subordinate configuration control boards functions 
are: [Be£. 26] 

1. GPS JCCB Working Group: The working group serves as 

the technical staff to the GPS JCCB and reports 
directly to the chairman. 

2. GPS Control Segment Configuration Control Beard (CS 
CCB) : The CS CCB is responsible for all configuration 
control of the Control Segment with ■ approval 
authority to approve Class 1 changes that dc not 
impact the space vehicle and/or user equipment. 

3. GPS Control segment Computer Program Sub Board (CS 

SPCSB): The CS CPCSB may approve Control Segment 

Class 2 changes on CIs and computer program configu- 
ration items (CPCI* s) identified in the CS CPCSB 
charter . 
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Figare 4.1 GPS CONFIGURATION CONTROL STROCTOHE. 



39 




4. GPS Ccntrol Segment. Configuration Sub Board (CS CSB) 
at SAC/MCS (Strategic Air Command/Master Control 
Station) --The CS CSB at SAC/MCS operates similar to 
the one at WE-ALC except it may approve class 2 
organic software changes and emergency class l 
changes if required to maintain satellite orbital 
configuration . 

5. GPS Control segment Computer Program Screening Panel 

(CS CPSP) : The CS CPSP is responsible fcr validating 

proposed changes and preparing recommendations for 
submission to the CS CPCSB/tf R- ALC . 

6. GPS User Equipment Joint configuration Control Board 

(UE JCCB) : The JSSfl chairs the UE JCC3 and approves 

class 1 changes that do not impact the space vehicle 
or the control segment and all class 2 changes. 

7. GPS UE Computer Program Screening Panel (UE CPSP): 
The UE CPSP functions in the same capacity as the CS 
CPSP with respect to validation of proposed changes 
and recommendations to the UE Computer Program 
Configuration Sub Board. 

8. GPS UE Computer Program Configuration Sub Board (UE 
CPCS3); The UE CPCSB reports to the UE JCCB and may 
approve class 2 changes on the User Equipment. 

9. PM/SM Affected, U3AF, USA, U3N and other agencies all 
have CCB's that report to them on configuration 
control issues germane to their respective service. 

D. GPS USER SEGMENT DEFICIENCY REPORT/CHANGE PROCEDURES 

User activities below the depot level prepare and submit 
UE deficiencies and change proposals to the respective 
service CCB. The flow chart for processing user segment 
deficiency reports and change proposals is shown in Figure 

4.2. 
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Figure 4.2 OSER SEGHEHT COSFIGUEATION FLOW DIAGRAM. 
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Figure 4.2 points out the successive chain of boards and 
sub beards than must review rhen approve or disapprove each 
change proposal. Depending on priority (emergency , urgent or 
routine) changes will be implemenred individually or held 
for the next block release. This decision will be made by 
the JSSM and based on the service system and using activi- 
ties requirements. If change reguesrs are held for block 
release a time lapse of one year or more could conceiveably 
elapse before the user acriviry wirnesses the final produce 
of a change proposal. 

Configuration Status Accounting is used to coordinate, 
record and report all the configuration changes affecting 
configuration items and computer program configurations 
items to the Program Manager. MIL-STD-432A governs the use 
of any data content and format necessary to perform status 
accounting. Status accounting is a continual process suple- 
mented by Physical and Functional Configuration Audits. 
These audits should be performed at a time interval deter- 
mined by the requirement for updated baselines. With the 
block change concept the audits should precede the implemen- 
tation of the block change. Status accounting records the 
baseline (approved configuration) and the implementation 
status of changes to the baseline. This verifies whether or 
not the decisions of the GPS CCB's are being implemented as 
directed. Timely and accurate change reporting by the 
contractor or GPS activity is paramount for a precise 
configuration control system. 
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V-. CON FIGDR ATION CONTROL MM^EMENT STRDCTORE FOR NAVY 

UNIQUE IT^S 

This chapter is limited to the function of configuration 
control for Navy Unique User Equipment Items of the GPS 
system. Consideration will be given to the proposed manage- 
ment structure to facilitate this function and how this 
function interfaces with the configuration management func- 
tion cf the DoD commcn UE segment. 

A. MAJOR AGENCIES/R ELATION SHIPS 

The United States Air Force is the executive agency for 
the GPS program, and is responsible for providing central- 
ized and integrated management of DoD common user equipment 
which will be in multi-service/ agency use. As the execu- 
tive agency, the Air Force is responsible for maintaining 
the commonality and standardization of all DoD common equip- 
ment. The retention and protection of GPS user equipment 
commonality and standardization are obligatory management 
responsibilities- [Ref. 27] 

The Navy's GPS Program encompasses the user equipment 
for aircraft, surface ships and submarines, with the use of 
all three GPS systems (single channel, dual channel, five 
channel). The wide application of GPS in the Navy brings 
into play the three System Commands (NAVAIR, NAVSEA, 
NAVELEX) and the Chief of Naval Material (PM-1) . The very 
diverse characteristics of the respective operational plat- 
forms and weapon systems dictate procedural variations in 
the implementation of effective management functions. The 
Navy has specific responsibilities for ensuring the ccraraon- 
aiity and standardization cf software and hardware of 
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Navy-uniqu€ user equipment and for providing support zo tne 
Air Force in maintaining commonality and standardization for 
DoD ccmmcn equipment. 

Figure 5. 1 graphically identifies the organizational 
interrelationships cf the Navy System Commands and the JPO, 
both before and after PMST. The major effect by P.1RT on the 

support management structure for the Navy is the change from 

JPO to JSSMC final approval authority. 

The GPS JPO has full program management authority and 
responsibility until the planned PMRT occurs in FY 87. 

Following the PMRT, those responsibilities will be assumed 
by the GPS JSSao located at Hamer Robins Air Logistic 
Center (WE-ALC) . 

The Navy Support Management Structure prior to PMRT 
is headed by the Program Manager PME-106-2 and is assisted 
technically by the SYSCOMs with consultation provided by the 
CEA, LFAs and the PSSAs. The headquarters element is 

responsible for setting the overall management policies for 
the Navy Program, including the design and implementation of 
the total Navy program organization structure, for dele- 
gating administrative and configuration management 
resposibilities and for providing direction to and funding 
cf program participants. The Navy support management struc- 
ture remains the same after PMRT except it now reports to 
the JSSMC via the Navy Configuration Control Board, which 
will be chaired by PME-106-2. 

PME 106 has the overall responsibility and authority for 
all phases cf the Navy GPS program as shown in Figure 5.1. 
PME 106 is the central management activity responsible for 
the total Navy acquisition management of the Navy GPS UE 
program. Responsibilities include Configuration Management, 
Acquisition Logistics, Specifications, Acquisition, 

Cataloging, Provisioning, Maintenance and Interservicing, 
Spares Requirements, Budgeting and Funding, Financial 
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Figura 5.1 SOPPORT aaNAGEMENT STROCTORE. 
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PME 106-2 is 



Management , Train ing , and UE Installations, 
directly responsible to PME 106 for all GPS related matters 
and interfaces, and is also the Navy Deputy Program Manager 
at the JPO. 

EIEX-08 is the central management activity responsible 
for total Navy ILS, Systems Effectiveness Engineering 
Program, Maintenance Effectiveness and Supply Support of the 
Navy GPS UE program. 

The second principal element of the Navy GPS support 
management structure is comprised of the designated support 
activities participating in the development, testing, evalu- 
ation, support and utlization of the GPS system. This group 
of organizations includes the CEA, LFAs and PSSAs with 
responsibilities for various Navy laboratories, depots, test 
and evaluation activities and user activities. The active 
membership cf this group will change from time to time as 
the GPS system evolves from development to ultimate deploy- 
ment. Organizationally, this element is depicted in Figure 
5.1. [Ref. 28] 

The contractor position in the support management struc- 
ture is an advisory member. The contractor is a critical 
contributor of information concerning design and production 
management, which ties directly into configuration control 
management. The contractor will also supply all technical 
support fcr the first 2 to 3 years prior to the Navy’s take 
over cf organic support. The benefit from the contractors 
parricipat ion, will rely heavily upon the amount of coopera- 
tion and effort that the contractor places on the 
development of the GPS system and the antitude taken in the 
advisory role. 

The GPS creates the need for numerous vertical and hori- 
zontal relationships within the Navy for configuration 
control management. The support structure depicted in 
Figure 5.1 indicates these relationships and also the single 
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interface bstwasn PMS 106-2 and th= JPO prior *c P:iST and 
JSSMC after PMHT. 

B. CONFIGOEAnOB MANAGEMENT STRUCTOSE HARDHA,RE/SOPTHARE 

The Navy configuration management strucrure was planned 
around the most complex case. The complexity of the ?ai is 
a product of the amount of embedded computer programs being 
designed into the FMI and the interface between the FMI and 
the BPU. The design possibilities lie between two extremes. 
At the cne extreme is what we will call the "smart" FMI, it 
would be capable of preprocessing all data flowing between 
the RPU and the host vehical and would not require a stand- 
ardized I/O interface between the RPU and the FMI. This 
implies that the smart FMI would contain all the required 
computer pregrams to process all data concerning the GPS and 
be capable of formatting the data for all host vehicles. 
The design would allow for the maximum commonality among 
FMIs for the Navy host vehicles. Malting this FMI program- 
mable to accommodate the integration aspect of the different 
host vehicles could, at the extreme, require only one FMI 
conf iguraticn, along with separate software programs that 
could be loaded into the FMI for each type of platform. At 

the other extreme is what we will call the "dumb" FMI. In 

very simplistic terms the FMI would be nothing more than a 
junction box that would accept data from a standardized I/O 
interface between the RPU and the FMI and direct the data to 
the appropriate sensors in the host vehicle. This would 
most likely require a unique FMI for every platform. 

The FMI baseline is presently specified in generic terms 
and the product configuration baseline will not be estab- 
lished until the production decision is made at DSARC III 
sometime in FY 84. Both contractors are working under a 
Fixed Price development contract, which limits the Navy's 
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input of preciss design tradeoffs during the FMIs develop- 
ment. Given uhis fact the mcst probable outcome will be ro 
purchase initially the FMIs that are designed by the 
contractcr, and tested during lOTSE. Therefore; zo be able 
to do configuration control management the need to develop 
plans for the most complex case based on the proposed 
contractor designs requires a management structure that will 
be capable of handling both hardware and software configura- 
tion control. The structure must also be designed to 
interface with all the various activities and support 
elements involved in GPS. 

The Navy configuration management structure is headed by 
the program manager, PME 106-2 and assisted technically by 
the SYSCOas, with consultation provided by the System 
Management Office (SMO) at CEA, System Support Office (SSO) 
at the LFAs and the Platform System Support Activities 
(PSSAs) . Together these activities maice up the headquarters 
element, which is responsible for the overall program direc- 
tion. other Activities provide specialized assistance as 
required. [Ref. 29] The headquarters element organization 
relationships are depicted in Figure 5.2. 

During the development phase and prior to the establish- 
ment of the NCCB, LFA C RBs , the developing ccntractor 
submits all change proposals directly to the JPO pregram 
manager [Ref. 30], who has final approval/disapproval 
authority. The ccntractor performs the configuration 
control management function and documentation during this 
phase and coordinates his actions through the JPO. 

The Navy Configuration Management Structure (CMS) comes 
into play during the transitition phase from ccntractor 
support to Navy organic support. This structure relies 
heavily on the configuration management data that is devel- 
oped and updated by the contractor, with inputs by by the 
Navy representative in the JPO. During this phase, and 
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Figure 5.2 CCNFIGOS ATIOa BAHAGEHEHT STROCTORE. 
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after the NCCB and LFA CRBs have been established, rhs 
contractor will simultaneously submit all change proposals 
to the NCCB chairman and the JPO, who retains the approval/ 
disapproval authority throughout the transition phase. 

The contractors production management plans require 
coordination with the JPO during rhe development and transi- 
tition phase. This coordination is made more difficult due 
to the fact that the contractor is working under a fixed 
price contract and any changes require contract negotiation. 
The ccnrractors production plan along wirh the product 
configuration will become firm at the conclusion of develop- 
ment and prior to production of the GPS UE. The contractors 
producticn plan will influence the cost and the ease of 
incorporating changes into the design during the production 
period. The worst case planning concept implies the plan- 
ning for numerous changes during this period. Therefore; to 
implement changes the production plan will have to be flex- 
ible and flexibility normally means a greater cost. 

The support phase will coincide with the AF PMST, which 
is scheduled for FY 87. During this phase all contractor 
change proposals affecting the Navy UE CIs/CPCIs will be 
submitted to the LFAs for inclusion on the agenda and 
presentation at the CSB meeting. This ECP flow is included 
in Figure 5. 10 . 

The Navy configuration control management plans rely on 
the establishment of the NCCB and CRBs early in the transi- 
tition phase. Along with their establishment a data system 
must be established to accept the configuration data (i.e. , 
product baseline) from the contractor. The data system 
should handle not only the Navy unique UE, but also the data 
interface with the DoD common UE items. This data will 
undergo continuous update during the transition and support 
phase. The data must be available and in useable form to 
facilitate the configuration contrnl function. The Navy 
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needs to know exactly what items it has and whai. *:he 
configuration of each item is in real terms. 

Planning the configuration management structure around 
the most complex case implies that the support facilities 
for configuration control be established to support the 
configuration control management of both hardware and soft- 
ware. To accomplish the configuration control of software, 
a minimum of three Navy Software Laboratories and two Land 
Base lest Sites must be established. This arrangement of 
labs is depicted in Figure 5.3. The software laboratories 
at XLFA and ALFA could be eliminated with the use of a dumb 
FMI. The software laboratory at the CEA will be necessary 
under either concept to allow for centralized management and 
first order impact studies of ECPs. The pivotal roles in 
the management structure are the roles played by CEA, XLFA 
and ALFA. 

• C entra l Engineerin g Activit y (CEA) 

The CEA acts as the NAVSLEX SYSCOH technical agent 
for in-service engineering for the SPS system. As such, the 
CEA supports PME 106-2 in ensuring that the GPS UE remains 
continually effective and in combat ready state for fleet 
use as long as it is part of the Navy inventory. CEA will 
provide the central configuration control management func- 
tion for the Navy GPS UE. 

It is the opinion of the researchers that the 
distribution of UEs throughout the Navy, as well as the 
broad interest in utilizing the mission advantages that GPS 
can provide, will result in a continuing stream of hardware 
and software changes. The largest amount will be software 
changes, because the GPS is appro xiamately 80% software. 
These inputs will get to the CEA through various media. 
Inputs from the fleet activities and the SYSCOMs will be 
routed via the respective LFA to the CEA. 
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Figure 5.3 SOFTWARE LABS/LAHD BASE TEST SITES. 

Inforaation will be coasolidated by an initial 
screening group that will review all incoming data and 
summarize/categorize problems, issues, etc. in a concise 
format. These summaries will be grouped into three catego- 
ries for assessment and response. [Ref. 31] 

1. DOD COMMON/NAVY COMMON 

2. DOD COMMON 

3. NAVY AIR/SEA UNIQUE 

This process is graphically displayed in Figure 5.4. 
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Figure 5.4 INPOTS TO CEA. 

Each of the CSA engineering sections and SYSCOM 
component units, working in coordination with each ether 
will determine problem definitions, solutions, specification 
to implement new requirements, objectives to deal with tech- 
nical issues, system enhancements to utilize technological 
advancements, work packages for integration and recommenda- 
tion on ECPs received. The coordination of this effort is 
very difficult and is crucial to the commonality objective. 
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Written statements of agreement should be developed zo 
implement this coordination. 

Analyses and tests will be performed to isolate the 
source of the reported problems. Problems relaned rc plat- 
form systems or within JSSMO cognizant items will be 
examined in coordination with personnel and facilities of 
the SYSCCMs and the JSSMO, respectively. Having isolated 
the source of the problem, alternate solutions will be 
explored through analysis. The approach taicen will be coor- 
dinated by the appropriate Project Engineer with tasicing 
approval through the CEA. 

The full complement of CEA, JSSMO and SYSCOM facili- 
ties will be utilized to determine the best fix for each 
problem. Solutions will be examined through laboratory and 
platform tests, as required. Test reports summarizing test 
results and recommendations for implementation will be 
prepared . 

New system requirements, technological issues and 
ECPs received from PfAs stemming from fleet utilization, new 
mission needs, etc. will first be evaluated to determine 
alternative approaches to implement these capabilities and 
to identify their impact on the UE and other platform 
systems. It is recognized as these inputs are evaluated, 
that the implementation integration of all these new 
requirements will require close coordination and interplay 
with all agencies involved. This should be handled through 
a Preplanned Product Improvement agreement. The product of 
these efforts will be a unified response and result in 
specification changes, readiness improvements, platform 
integration packages or ECPs. Each will be accompanied by a 
detailed iirple mentation plan which will ensure that the 
total program impact of each change has been accounted for. 
Where JSSMO cognizant 'JE are involved, a coordinated plan 
will be prepared to be sent to the JSSMO. [Ref. 32] 
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Figure 5.5 ASSESSHEMT AMD BESPOHSE. 

To fulfill the central management funcrion and main- 
tain the Navy commonality of GPS US, CSA musr coordinate the 
inputs form the SYSCCMs and the LFAs. This coordination 
will allcw for a unified response to the Navy configuration 
Control Board (NCCB) and ensure the commonality of the GPS 
system is maintained within the Navy. 
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The two LFAs for the Navy GPS program are NAVELSX 
LFA (XLFA) located az the Naval Electronic Systems 
Engineering Canter, San Diego (NESEC) and the NAVAI5 LFA 
(ALFA) located at the Naval Avionics Center, Indianapolis, 
Indiana (NAC). NESEC will perform the csr.zral configuration 
management funcrion fcr NAVSEA, which will consisz of all 
shipboard applications of the GPS syszam. NAC will perform 
the cenzral configuration management function for NAVAI3, 
which will consist of all airborne applications of the GPS 
system, [Ref. 33] 

The XLFA and ALFA will provide engineering and tech- 
nical support, perform fleet supporz activizy (FSA) 
functions and configuration control functions for bozh zhe 
hardware and sofzware for their respective Navy unique UZ. 
The management structure shown in Figure 5.2 indicates the 
direct lines of communications that are required zo unify 
the Navy configuration control effort and to update and 
support the Navy unique GPS hardware and software through 
the life-oycle of the system. 

An element of the LFAs will be zhe support integra- 
tion activity (SIA) for the Navy GPS integration program. 

The primary function of the SIA is to provide follow-on 
engineering services during DT&E to support the development 
of the FMIs during Phase III. The LFAs will identify and 
control the configuration ( hardware/sof tware) for the GPS OE 
platform interface (FMI) . this will be a coordinated effort 
with CEA as the pivotal point of intraservice coordination. 

A Land Based Test Sits (LETS) will be established at 
the LFAs to support the GPS integration program and 
software/hardware changes through the life-cycle phases of 
the GPS program. An extensive software repository including 
firmware, verification and burn-in functions for the Navy 
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plazforms/ GPS interfacas and the Master Program files for 
the system FMIs will reside at the LBTS. [Eef. 34] The LBTS 
will include a software laboratory to perforin the necessary 
functions for processing software changes. 

Located at both LFAs, will be a Configuration Review 
Board (CH5) to review and evaluate all changes to the Navy 
GPS UE and assess the impact of the changes in their respec- 
tive areas of expertise. A recommended compcsxtion of the 
CRB is shewn in Figure 5.6. [Hef. 35] 

The CRB has no final approval/disapproval authority 
for ECPs. It will review the ECPs and submit them along 
with their assessments and recommendations to the CEA for 
evaluation and forwarding to the SY3C0M CCBs and the NCCB 
for approval/disapproval. 

A large task for the LFAs will be coordination of 
the PSSAs; however this must be done to unify the Navy in a 
manner that will allow for maintaining commonality along 
with an aocurate product baseline. The Navy PSSAs are the 
field activities responsible for maintenance of systems 
resident on platforms that are interfaced with the GPS 
system. The PSSA will be responsible for conducting certi- 
fication of GPS configuration changes to ensure 

compatibility with interfaced systems. The functions that 
must he performed by the PSSA are as follows: [Ref. 36] 

1. Review and coordinate the analysis of all platform 
problem reports and all proposed changes that impact 
the GPS system with the appropriate LFA. 

2. Ensure that all platform system problems and proposed 
system changes related to the GPS system are analyzed 
for impact upon GPS UE. Whenever an impact on GPS UE 
is identified, the engineering data of the changes 
are submitted to, and coordinated with the appro- 
priate LFA. 
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Figure 5.6 CONPIGUBATIOM REVIEW BOARD. 

3. Perform the certification of GPS UE changes that 
affect the interface characteristics and functions of 
the related FMI unit. 

4. Participate on the CSBs as required. 
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Du€ to the crgar.i zation structure of the NAVAIR 
PSSAs a major coordination problem exists for NAC. Working 
agreements should be sought as soon as possible tc ensure 
that ALFA is established as the central and lead control 
agency and that the single interface between ALFA and CEA 
is the one that is established. without this type of 
arrangement the proliferation of different CIs/C?CIs between 
NAVAIE PSSAs could result. This would run counter tc the 
stated objective of maintaining commonality in the GPS 
program . 

3* N avy C onfi gu ration Contro l Board (NCCB) 

The NCCB will be responsible for the Navy UE configuration 
management through the life-cycle of GPS [Ref. 37], A 
recommended composition of the Navy Configuration Control 
Board (NCCB) is shown in Figure 5.7. The NCCB will review 
proposed ZCPs and provide technical approval or disapproval 
based on these reviews. It will determine overall system 
impact of the proposed change and assure that the ECP covers 
all subsystems affected. 

It is the opinion of the reasearcher that the NCCB 
should be chartered with the authority for final approval/ 
disapproval of all ECPs that affect Navy unique UE CIs and 
CPCIs. Fcr these ECPs an information copy should be sent tc 
the Joint Configuration Control Board (JCCE) located at 
JSSHO fcr update of the central overall system configuration 
data file. 

C. ECP FLOW FOR NA7I OB 

All proposed changes to the system will be classified 
with regard to their total impact on the GPS system, 
existing documentation, and cost effectiveness. Change 
classifications and justification codas will be in acccr- 
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Figure 5.7 NAVY CO NFIGORATION CONTROL BOARD. 

dance with D0D-STD-480A as outlined in appendix C and D. 
Proper classification ensures ECPs will be adequately 
reviewed. Class I changes are further identified as to A or 
E in accordance with the following; [Ref. 38] 

1. CLASS lA: A change to the operational system which 

requires a conjunctive system software and hardware 
change. 
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2. CLASS 13: A change zo the operational sysreni which 

dees nor require a conjunctive system software and 
hardware change 

Class lA and IB changes will be assigned priorities in 
accordance with DO D-STD-48 OA as described in appendix E, 
The priority assigned will be the major factor determining 
the time required to fully process the ECP, 

It is the contention of the researchers that the ECPs 
will mainly fall under the priority of routine with a few 
exceptions that will fall under the urgent priority. This 
contention is based on the researchers interpretation of 
Mil-Std-480A (Appendix C through E) and the operational 
aspects of the GPS as a navigational aid. This can be 
accomplished through the design of the FMI and the integra- 
tion of the GPS system into the weapon system platforms. 

It fellows from the above that if the major portion of 
the ECPs are routine then the configuration management 
structure and documentation flow should be designed around 
the time requirements and priority of the routine ECP. The 
few Urgent ECPs could be flagged and expedited cn a case by 
case basis through the system. A major impact of routine 

ECPs would be in the utilization of block changes. A time 
table could be established for implementation of the ECPs as 
one block change (for example a yearly basis) . This would 
allow for the collection of ECPs and the most effective use 
of a change. Using this method one block change could solve 
a number cf problems. 

A decision to process ECPs in this manner would allow 
for a stable production plan for the contractor and a firm 
planning horizon for the retrofit modifications to opera- 
tional FMIs. The ECP flow through the configuration control 
management structure is depicted in Figures 5.8--5.10. 
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COMPOTES BASED MA NAGEHEMT I NFORMATION SYSTEM 



A. COMPOTES DATA BASED MIS A TOOL FOB CM 

GPS presents a very large problem in the management 
arena cf coordinating the various and diversified management 
areas. The JSSMO, as stated previously, is responsible for 
the tctal DoD acquisition/engineering management of the GPS 
OE program after PMRI in FY 87. Hesponsibilites include 
configuration management, acquisition logistics, engi- 
neering, specification, acquisition, cataloging, 

provisioning, maintenance and inter-servicing, spares 
requirements, budgeting and funding management, financial 
management, training and UE installation. The three 
services; Navy, Army and Air Force, are responsible for the 
above management areas for the service unique items. With 
NATO and other agency use of GPS UE the scope of the coordi- 
nation and data management prcblems is indeed very large. 

Coupled with the above is the fact that there are three 
GPS sets; single channel, dual channel and five channel, 
that make up the GPS UE family. These sets will be 
installed on various platforms bringing almost all areas of 
each service into the coordination and data management 
problem. Commonality among the diffarent sets, which is 
accomplished through the use of common SSUs with common 
CPCIs, and the commonality within the sets across various 
platforms is a stated objective of the GPS program. In 
crder to maintain this commonality and effectively manage 
the GPS resources the management activities need to be 
centralized. To support the JSSMO, Navy, Army and Air Force 
in centralizing the management activities and to provide the 
necessary in-house engineering support for the GPS UE 



64 



program, an on-line real-time computer based management 
information system (MIS) is required. This system can then 
provide the "TOOL” to manage and control the UE support 
elements contributing to the LCC throughout the GPS program 
life cycle. 

The idea of a computer based inf ofmation system for the 
configuration management of GPS UE is not foreign to the GPS 
program. Lt. Thomas Atrahamson attended a briefing at Robins 
AFB on 25 January 1983 and Lt. Gerard Mauer attended a 
briefing at the JPO on 1 February 1983. Both briefings were 
conducted by Mr. John F ens termachec , who is the Navy Deputy 
System Manager and the UE Program Manager for JS3MO. The 
briefings dealt with the subject of a computer based MIS, as 
a tool for configuration management. Chapter six is devoted 
to taking a look at a computer based MIS that could be used 
as a tool fcr management and control. The observations and 
conclusions presented in this chapter are based on the 
researchers understanding and intarpations of the informa- 
tion presented at the two briefings. 

The coordination of the GPS UE program relies heavily on 
effectively handling the massive data reguiraments generated 
for support of system engineering. The management informa- 
tion system must be centered around making changes to a 
design (i.e., ECPs) and the monitoring of the impact of 
these changes to the product baseline. The biggest problem 
in the past has been tha tracing of a problem from genera- 
tion by the fleet or a user activity through its resolution, 
and all changes that take place until it comas out tha door 
as a mod-kit to solve the problem. 

An on-line real-time computer based MIS utilizing 
distributive processing will have as its primary function 
the support of tha centralized management activities by 
identifying, scheduling, controlling, auditing, reviewing, 
accounting, processing and inter-relating a life cycle flow 
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of the following support data related to controlling the GPS 
DE baseline: 

1. ECF TRACKING AND MANAGEMENT DATA (the central core) 

2. INVENTORY/CONfIGUEATION STATOS ACCOUNTING DATA 

3. ITEM PP.OCOREMENT/SOPEORT DATA 

4. COMPUTER RESOURCES SUPPORT DATA 

5. BUDGET/LIFE CYCLE SUPPORT COST DATA 

6. LSA MODELING SUPPORT DATA 

7. PROGRAM SCHEDULING/PLANNING DATA 

8. FLEET READINESS MANAGEMENT DATA 

9. DISCREPANCY/SERVICE REPORT DATA 

10. MINUTES/ACTION ITEM REPORTING DATA 

The data base required to operate this system would be built 
during the transition phase, which would include the product 
baseline and all other contractor and test data. This would 
put the MIS fully operational at the begining of the organic 
support phase of the GPS UE program. 

The data base system would be divided into three major 
sections and operated on a distributive bases, as shown in 
Figure 6.1. 

1. I NFOT/F I LE MAINTENANCE SECTION I This section is 
ccmpcsed cf on-line data entry, file maintenance, 
data/ file, monitoring of ail support data work files 
processed/generated by the assigned support engi- 
neers, data entry, and data based administrators. 
The data in this section is in a changing mode and 
provides a mirror image of the master data base. 

2* INQUIRY DATA MSE INFORMAT ION MANAG EME NT SECTION: 
This section is composed of the master data bases 
retaining current support data information generated 
from the work files. This section is used primarily 
as a management tool for data base administrators, 
and program managers as an on-line inquiry/ 
information management system. This is an 

interactive system with only read data. 
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Figure 6.1 SECTIOH OVERVIEW. 

3* ADMINIS T RAT I VE SECT ION; This section is composed of: 
a.) Simplified inner- of f ice word processing system for 
office letters, memos, and ere. 

b) Document word processing sysnera for large docu- 
ments requiring independent controlling of 
document data. 

c) Graphics section for generating management graphic 
illustrations for scheduling, planning, and etc. 

The medern day computer puts the capability of such a 
MIS at our disposal. The major item will be the development 
and maintenance of the software to operate a real time 
interactive, distributive data based processing system. The 
existence of cross country telecommunication networks allows 
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for rh€ csntr al izar icn of this systea at the JSSMC, with 
ramote terminals and time sharing capabilities for the 
respective Services and agencies. Thus; the technology 
exists for the utilization of this configuration management 
tool . 



B. HIS 4ND THE ECP 

The inter-activity of the data bases will allow manage- 
ment to us= ’’WHAT IF" drills in determining and reviewing 
solutions to GPS US problems. Proposed ECP solutions can be 
input and an impact study can be accomplished on a real time 
basis, along with a LSA in accordance with fiIL-STD-1338-1. 
Therefore; when a solution is generated the inventory, 
support and LCC impacts can be readily obtained prior to 
putting the solution into effect. This would allow the use 
of an iterative process to determine the best solution 
considering trade-offs to the problem. With the GPS sets 
being 80^ software the tracking of software changes can be 
accomplished, along with the impact study of each software 
change. When a computer program change is required the 
system identifies that change to the new CPCI. The software 
change is then linked to the firmware part number (chip) , 

which is further linked to the S RU that chip is on. 

Therefore; management would know the SRU effected the chip 
and the computer programs that are on that chip. This 
becomes especially important when dealing with interface 
compatability between DoD common and Service unique. 

Each ECP generates a record for the problem. This 
record remains active until the ECP is closed out with a 
mod- kit installation. The record is kept for historical 
data. Working on the concept of block changes this aspect 

allows management to monitor the changes and effectively 

coordinate them into a block change. This provides a 
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complete status tracking of each SCP throughout its review 
process and couples with the ECP the impact review of that 
change. Cutting across the ECPs allows for establishing the 
budgeting information required for the purchase and imple- 
mentation of the block change. In order to keep the ECPs on 
schedule a comm log system would let each activity know if 
there is an action item for them in the system. Coupled 
with this a PERT network would show each activities review 
response date. 

The computer based MIS would combine rhe inventory and 
configuration management system to accomplish asset 
accounting not only for DoD, but for each of the services. 
This system has the capability of telling management what 
the asset is, where it is located, its condition and compat- 
ability. Each platform creates a separate record for 
tracking the location of the LRUs and the SRUs. This allows 
also for the system to show the impact by platform. 



C. MIS POTENTIAL PROBLEMS 

The system discussed sc far seems to be the dream tool 
for configuration control management of the GPS UE. 
However; certain areas appear to the researchers as poten- 
tial problems requiring further research. 

• Da ta Sec uri ty ; The system to operate completely and 
effectively will require priviledged data and 
possibly classified data on file or accessabls 
through other computer systems. Without the proper 
data security contractors could obtain priviledged 
data allowing them an unfair advantage in future GPS 
related contracts, and classified data could fall 
into the hands of the wrong people. What security 
measures can be taken to ensure only the people with 
the need and clearance can access this data? The use 
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cf user identification codes and special coded files 
does not seem to fully answer this question, 

2* Quality Assuranc e of Input Data : The potential 

problem is expressed by the old saying of garbage in 
garbage cut. The system can provide some quality 
assurance through the use of data cross checking, 
this would eliminate the possibility of inputting 
incorrect part numbers, NSNs, or ECP numbers and etc. 
into the data base. The use of designated data base 
managers to review all inputs from each activity, 
will also provide some quality assurance. However; 
will this provide enough quality assurance to ensure 
an accurate up-to-date data base? 

3. Hardwar e Obsolesc ence; Advances that are being made 
in computer technology, brings the hardware obsoles- 
cence problem into view. A possible solution to this 
problem would be for the government to purchase only 
the data based system software and lease the required 
hardware. This not only eliminates the hardware 
obsolesence problem but will also spread the cost cf 
the hardware over mors years. Centrally locating the 
computer system at the JSSMO with remote terminals on 
a time sharing basis, the problem of the diffusion of 
configuration management system software would be 
curtailed. The major question that must be answered 
in this area is does the benefit outweigh the cost of 
such a system? 

C q nf igu r a ti on Contro l of Data Base S oftwar e ; The 
configuration control of the data base MIS software 
presents another potential problem. A configuration 
control board with members from each of the user 
communities would need to be established to review 
and coordinate changes required in the MIS software. 
Designing the MIS software in a modular format and 
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using high-level computer language will allow 
necessary changes -o be made in an efficient manner. 
The guastion still remains abour who will chair such 
a board and who will make rhe final decision on the 
changes. 
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7II. SUUaARY 

A. ANALYSIS OP THE OVERALL SYSTEM 

As suatsd earlier, the primary objec-ive, of ::he rhesis, 
was to freeze the dynamic nanure of the configuration 
management plans and examine the configuration control 
aspects of the plans. The risk nhat is taken by doing rhis 
is rhe implication that the configuration control management 
plans exist and will continue to exist as they are seen at 
this one point in time. The realistic picture is that ever- 
ything is continually changing and these changes will impact 
configuration control. What freezing the plans in time does 
is to allow the researchers the opportunity to examine it 
and present a point estimate for comparison. Therefore, the 
problems and conclusions reflect the configuration control 
management clans at this point in time. 

The configuration control management plans for the DoD 
common and the Navy unique CIs and CPCIs have all the 
required and necessary pieces to allow it to evolve into an 
effective and feasible plan for configuration control during 
organic support. The conception and plans to incorporate a 
computer based aiS as a configuration management tool shows 
perceptive insight into the importance and complexity of 
configuration control management for GPS UE. This tool also 
offers the ability to integrate not only configuration 
management among the different services, but also inventory 
and logistics support, which is necessary to provide a 
control system that will monitor the GPS UE in an efficient 
and effective manner. 
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To arrive at the overall conclusion thar the configura- 
tion control management plans are manager ially sound, rhe 
researchers looked for items that they felt were crucial. 
The first item was the baseline management concept. We 
found that a functional baseline existed in phase 1 and an 
allocated baseline exists during phase 2. Work is in 
progress to establish a product baseline for phase 3 and 
configuration control management plans will use the product 
baseline as its basis. 

The researchers arrived at the conclusion that the 
management plans acknowledged the differencn between hard- 
ware and software conf igu rat ion control. The necessary 
support documentation and facilities for software configura- 
tion control were in the plans. The positive point here was 
that software changes were not looked on as maintenance, but 
were considered as design changes. The software concept is 
very important due to the fact that the GPS UE is apprcxia- 
mately 80?E software and this is the area seen as having the 
greatest potential for change. Thus, a majority of the 
costs associated with change proposals will result from 
software changes. 

The other critical item was the management structure 
itself. The plans acknowledged the need for centralized 

management cf configuration control to meet the objective of 
commonality. The researchers understood the plans to place 
the JSSHC as the central manager of DoD common (JB and CEA as 
the central technical manager of Navy unique OE. The large 
number of agencies and platforms involved in the GPS program 
requires a centralized management structure. The Navy and 
the JSSMC have developed plans for the management structure 
that places control boards at the proper level to ensure 
regulation of the UE configuration. 
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The above elements lead the researchers to the conclu- 
sion that the prescribed configuration control management 
plans for GPS UE were sound. These elements are only the 
start of a good configuration control program and on their 
cwn will not evolve into an effective and feasible configu- 
ration control management system. Configuration control is 
not a fully automatic tool, it cannot be installed, 
programmed, switched on and left to run by itself. Like 
most tods, it will perform well only when used with skill, 
conscience, discretion and energy. 

B. HAJOB PBOBLEM 

The major problem in the opinion of the researchers was 
that the different elements for configuration control were 
not integrated. In order to continue forward and develop 
the plans into a working solution we feel than writren 
agreements of understanding must be developed and agreed 
upon by the major agencies. These agreements cculd then 
ensure rhat every agency was moving in the same direction in 
developing their plans for configuration control management. 
If the agencies are allowed to continue in an undirected 
environment, concerning configuration control, the objective 
of commonality will be lost not only in Service unique 
items, but also in the DoD common items. 

C. RECOMMENDATIONS 

Management attention must be focused on the development 
of written statements of agreement. These statements are 
required to establish the parameters and boundaries needed 
by the user agencies to bring their configuration control 
and integration management plans to maturity. 
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The following are recommendations rhat nhe researchers 
through their analysis have determined to be crucial to rhe 
GPS UE configuration control management plans. The list is 
not all inclusive, but represents a start, that we consider 
is in the right direction, for the evolution of the GPS UE 
configuration control plans into an efficient and effective 
configuration control system. 

1 • Agency Bound ary Agr eements 

A statement cf agreement should be developed that 
precisely identifies the boundaries for each agencys* area 
of responsibility and authority. An example would be to 
identify the boundary concerning changes affecting the 
interface between the RP(J and the FJII. The Navy, for 
instance, wculd be limited to changes affecting host vehicle 
unique FMIs. Any recommended changes to the FMI that affect 
the RFU wculd be out-side the Navy's boundary and would fall 
under JSSMO jurisdiction. What we mean is that no problem 
or enhancement cf the host vehicle or service unique FMI 
should be allowed to ripple back through the RPU. Without 
this limit specifically identified, each service could 
theoretically make changes to their respective FNIs that 
also alter the respective RPD capabilities. The ultimate 
result wculd be a significant loss in commonality and an 
increase in the complexity of configuration control. 

We recommend that any discrepancies or conflicts 
that affect inter service boundary responsibilities (for 
example, conflicts between the Navy and the Air Force) 
should be handled by the JPO prior to PMRT and the JSSMO 
after PMRT. Intraservice boundary disputes should be 
handled by their respective OF central management office, 
such as the CEA in the Navy. This would eliminate confusion 
between and within the Services concerning GPS UE boun- 
daries. Providing specific keystone agencies in each 
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service rc monitor and make decisions on the UE configura- 
tion control boundaries would help facilitate configuration 
control management. 

2- Cen tral ized Manaas m ent Agre ements 

The key to configuration control management is a 
centralized management structure. All DoD common OE will 
fall under the central management of the J3SM0, The Navy 
central technical management should be placed at CSA with 
NAC representing the NAVAIB platforms and NESEC San Diego 
representing the NAVSEA platforms. This type of a manage- 
ment structure is essential in maintaining the commonality 
objective and should be stated in writing as a statement of 
agreement between the Naval SYSCOtls, CSA ani the LFAs. 
Without a statement of agreement, coordination will be 
almost impossible. The coordination at this level is very 
important in maintaining control of the ECPs and obtaining 
the ccmmcnality objective. 

3. GFS In t e or at ion Agreements 

A firm integration plan for the Navy is needed 
immediately to allow the configuration control plans to 
evolve into a workable system. An integration concept 
statement of agreement should be developed. GPS is a navi- 
gational aid that can provide tne host vehicle with very 
accurate position, velocity and time. What we mean by a 
navigaticnal aid only can be seen best by an example. The 
example we will use is the integration of GPS into a high 
performance aircraft with an INS system. The GPS would 
interface only with the INS and act as an inflight cali- 
brator for the INS. Thus; the GPS data is fed to the INS 
and the INS in turn interfaces the rest of the sensors, 
which it already does. This type of integration would allow 
for simplification of the design (mainly software), limit 
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intagraticn problems and still utilize the highly accurate 
position, velocity and time data of GPS. This should be the 
strategy followed for integration. GPS should be used as 
the basic navigation aid among user platforms and electroni- 
cally tied into the present host vehicles navigation systems 
to permit continuous updating of the navigational plot. 

The concept of integrating GPS into numerous sensors 
and feeding data back and forth has created the effect of 
increasing the complexity of the design and configuration 
management. In order to develop a cohesive integration plan 
top down management direction is required. ??1S- 106-2 deci- 
sions fcr the Navy, with JPO concurrence, via CEA and 
through the LFAs should be made at this time to produce the 
necessary guidelines for the Navy platform managers, who 
must be the integration planners for their respective plat- 
forms. He feel that a decision to integrate GPS as a 
navigational aid only and not as a "do everything" system 
would allow for effective integration plans. Preplanned 
product improvement would be used to allow fcr future expan- 
sion and integration of the GPS system into updates of 
present weapon systems and subsequent new platforms. We see 
this as a natural extension of the GPS utilization after the 
initial system integration problems are resolved and its 
full capabilities are understood by the user agencies. 

4 . SCP Tr a c ki n q Agree m ents (During Testing ) 

Management attention needs to be focused on d=v el- 
oping a system to track and monitor all changes during the 
testing of the GPS OE. This requires a statement of agree- 
ment between the contractors and the JPO that states exactly 
how the changes will be tracked and monitored during DTSE 

and ICTSE. If these changes are not tracked and monitored, 

the required product baseline for configuration control will 

not be available at the end of the testing period. The 
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major problem exists during the overlap of DT&2 and OTS3. 
Needless to say, without this product baseline there can be 
no effective configuration control management. 

5 . R outin e Jloc k Chan ge Agreem ents 

An agreement should be developed, among all the 
involved agencies, that adopts the block change concept and 
establishes a time table for block change implementation. 
Integrating the GPS UE into the weapon system platforms as a 
navigational aid should result in the majority of the ZCPs 
being routine priority. This would reduce the amount of 
contract negotiation required to implement the changes 
during production and allow for scheduled planning of 
retrofit modif ications to the UE in operation. If this 
statement is not developed and accepted the control and 
timing of ECPs will be seriously effected. Thus, creating 
the need for a more complex configuration control management 
system, which will escalate the system's operating costs. 

6 • Software Labo r atory Agre ement s 

A written statement of agreement should be developed 
among the three Navy Software Laboratories. This agreement 
should define each laboratory's area of responsibility and 
its interface with the other laboratories. As stated in 
chapter five the two software laboratories at the LFAs could 
be eliminated with the use of a "dumb" FMI. However, it is 
the opinion of the researchers that to maximize commonality 
and to give the FMI the ability to effectively utilize and 
incorporate preplanned product improvement a FMI that lies 
between the two extremes would be optimal. This results in 
the need for software laboratories at CEA, ALFA and XLFA. 

The agreement should establish the CEA laboratory as 
the Central technical management point, suplemented by the 
LFA laboratories. Without this agreement duplication of 
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effort, increased development rime and increased cosr would 
occur with software ECPs. 

7 , U E Set s Procu remen t 

The configuration control management plans tend to 
reflect the degree cf complexity found in the GPS system. 
We feel that the selection of a 3 set UE family, with the 
objective of maximizing commonality in ail three sets have 
caused the management plans undue complexity. Further 
research is required to support the plan of purchasing the 
single channel and five channel sets only. We feel that 
along with this research the concept of dropping the common- 
ality objective between the two sets should also be 
considered. This would eliminate some of the configuration 
management complexity and could also free the design for 
more efficient operation. This would also provide the 
opportunity for the selection of two contractors, one for 
single channel and the other for the 5 channel. The 
overall benefits would be an increase in the technological 
base and prcduction capabilities of the GPS system. 
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APPENDIX A 
ABBREVIATIONS 



1 . 


AF 


Air Feres 


2. 


AFLC 


Air Fores Logisties Command 


3. 


AFR 


Air Feres Regulation 


4. 


AFSC 


Air Fores Sysnams Command 


5. 


AFSC/SD 


Air Feres Systems Ccmraand/Spacs Division 


6 . 


ALC 


Air Logisties Cenner 


7. 


ALFA 


Navair Lead Field Activity 


8. 


API 


Airframe Platform Integration- 


9. 


APL 


Applied Physies Laboratory 


10. 


C/A CODE 


Courss/Aequ istion Signal 


1 1 . 


CCB 


Configuration Control Board 


12. 


CCED 


Configuration Control Board Direetive 


13. 


CCBR 


Conf igurani on Control Board Request 


14. 


CEEL 


Contraet Date Requirements List 


15. 


CDU 


Cent lol/Dis play Unit 


16. 


CEA 


Central Engineering Aetivity 


17. 


Cl 


Configuration Item 


18. 


CM 


Configuration Management 


19. 


CMP 


Configuration Management Plan 


20. 


CMS 


Configuration Management System 


2 1 . 


CPCI 


Computer Program Control Item 


22. 


CPCSE 


Computer Program Configuration Sub-Board 


23. 


CPIN 


Computer Program Identifieation Number 


24. 


CPSP 


Computer Program Screening Panel 


25. 


CRB 


Configurtion Review Board 


26. 


CRISP 


Computer Resources Integrated Support Plan 


27. 


CRPA 


Contrcllsd Reception Pattern Antenna 


28. 


CS 


Control Segment 


29. 


CSE 


Configuration Sub Board 
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30. CSCCB 

31. DMA 

32. DOD 

33. DSARC 

34. DTSE 

35. ECE 

36. ECR 

37. ECS 

38. EPROM 

39. FCA 

40. FMI 

41. FCC 

42. FRPA 

43. FSA 

44. FY 

45. GPS 

46. lAW 

47. ILS 

48. ILSP 

49. INS 

50. I/O 

51. lOTSE 

52. ISF 

53. IVSV 

54. JCCB 

55. JPC 

56. JSSM 

57. JSSMO 

58. JSSMP 

59. LBTS 

60. LCC 

61. LFA 

62. LRD 

63. ISA 



Control Segment Configuration Control Bear! 
Defense Mapping Agency 
Department of Defense 

Defense Systems Acquisition Review Ccuncii 
Development Test and Evaluation 
Engineering Change Proposal 
Embedded Computer Resources 
Embedded computer System 

Electronically Progammable Read Only Memory 

Functional configuration Audit 

Flexible Modular Interface 

Final Operational Configuration 

Fixed Reception Pattern Antenna 

Field Support Activity 

Fiscal Year 

Global Positioning System 
In Accordance With 
Integrated Logistic Support 
Integrated Logistic Support Plan 
Inertial Navigation System 
Input/Outpu t 

Initial Operational Test and Evaluation 

Integration Support Facility 

Independent Verification and Validation 

Joint Configuration Control Board 

Joint Program Office 

Joint Service System Manager 

Joint Service System Management Office 

Joint Service System Management Plan 

Land Eased Test Site 

Life Cycle Cost 

Lead Field Activity 

Line Replaceable Unit 

Logistic Support Analysis 
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64. MCS 

65. MIL STD 

66. MIS 

67. NAC 

68. NATO 

69. NAVAIR 

70. NAVELEX 

71. NAVSEA 

72. NCCB 

73. NSSSC 

74. OPB 

75. OSD 

76. OTSE 

77. P Cede 

78. PCA 

79. PCV 
30. PEA 

81. PM 

82. PME 
33. PKR 
84. PHRT 
35. POS/NAV 
86. PSE 
37. PSSA 

88. RFI 

89. RPO 

90. SAC 
9 1. SD 

92. SESA 

93. SIA 

94. SM 

95. SPI 

96. S3U 

97. SSCCB 



Masrer Control Sraticn 

Military Standard 

Management Information System 

Naval Avionics center 

North Atlantic Treaty Organization 

Naval Air Systems Command 

Naval Electronic Systems Command 

Naval Sea Systems Command 

Naval Configuration Control Board 

Naval Electronic Systems Engineering Center 

Office of Primary Responsibility 

Office of the Secretary of Defense 

Operational Test and Evaluation 

Precise Navigation Signal 

Physical Configuration Audit 

Physical Configuration Verification 

Participating Field Activity 

Program Manager 

Project Manager, Electronics 

Program Management Responsibility 

Program Management Responsibility Transfer 

Positioning and Navigation 

Peculiar Support Equipment 

Platform System Support Activity 

Radio Frequency Interference 

Reciever Processor Unit 

Strategic Air Command 

Space Division 

Ships Fleet Support Activity 
Support Integration Activity 
System Manager 
Ships Platform Integration 
Shop Replaceable Unit 

Space Segment Configuration Control Board 
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98. SSO 


System Support Offios 


99. TWG 


Transfer Working Group 


100. OE 


User Equipment 


101. USA 


United States Army 


102. USAF 


United States Air Force 


10 3. OSN 


United States Navy 


loa. vsv 


Verificati ona and Validation 


105. WE-ALC 


Warner Robins Air Logistics Genre 


106. XLFA 


Navelex Lead Field Activity 
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APPENDIX B 
DEFINITIONS 

1 . BASELIN ES : A configuration iisnrification document 

or set of such documents (including, for example, 
computer program listings, tapes, card decks, etc.) 
fcrmally designated and fixed at a specific time 
during a program's life cycle. Baselines, plus 
approved changes to baselines, constitue the current 
configuration identification. There are three 

distinct configuration baselines; once established, 
they are maintained and controlled throughout the 
life-cycle of the item as the following separate 
baselines : 

a) FUNCTI ONA L BASELINE ; The formally designated 
functional configuration identification fixed as a 
product of the initial or concept exploration 
phase of the acquisition cycle. 

b) ALLOC ATED EASELINE: The formally designated allo- 

cated configuration identification fixed as a 
product of the demonstration and validation phase 
of the acquisition cycle. 

c) PBODUCT BA S ELINE : The formally designated product 

configuration identification fixed as a result of 
incremental completion of the configuration 
audits, during the full-scale development phase or 
as a result of the completion of the configuration 
audits as single events and a final product cf the 
full-scale development phase of the acquisition 
cycle . 

2* CCMPUTB R PBOG BAM : A series of instructions or state- 

ments in a form acceptable to an electronic computer. 
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which ire designed to cause the computer to execute 
an operation cr series of operations. 

3- CCMFUTBR PRO GRAM C ONFIGO fiATIQM ITEM (CP^) : A 

ccmputer program that is designated by the customer 
fcr configuration management and control. 

CC MPUTE R PROGRAM DOC UMENTA TION PACKAGE: An aggrega- 

tion of all program documentation that is required in 
the development of, or testing of, a specific 
computer program; i.e., flow charts, systems specifi- 
cations I and II, engineering data (design test, 
interface specifications, etc.) source listings and 
source prcgrairs, programmers notebook, and like data. 

5. CCMPU^R OPE R ATIONA L PR OGRA MS ; Computer programs 

required to operate a system. These programs are 
loaded in, and run in the computer equipment during 
system operation; i.e., Executive/Supervisor, 
Functional/Application, Input/Output, and like 
programs. ' 

6. CCMPUTER REFE RENC E M ANUA L; Manuals related to the 
use cf computer hardware or installation of computer 
hardware; i.e., manuals containing instructions or 
general information for the operational checkout or 
maintenance of computer hardware. 

• COMPUTE R SUPP ORT PRO GRAMS : Computer programs gener- 

ally used for the development and maintenance of 
other computer programs. Support programs include 
operating systems, assemblers, compilers, and 
loaders. 

8. CO MPUTE R TEST PROGRAMS: Computer programs developed 

to analyze or test systems and component performance. 
These programs include maintenance and diagnostic 
programs to analyze performance and to detect or 
isclate faults in computer equipment. 
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C C MPUTE R aES OUBCE S; The rotality of compu-t-sT equip- 
ment# computer programs# associated data and documen- 
tation# related supplies, services and persor.rxel. 

10. C CNFIGO B ATIOH MANAGEMENT; A discipline applying 
technical and administrative direction and surveil- 
lance to (1) identify and document the functional and 
physical characteristics of a configuration item# (2) 
control changes to those characteristics# and (3) 
record and report change processing and the implemen- 
tation status of each change. 

11. CONFIGURATION STATUS AC COU NTING; The recording and 
reporting of an approved configuration identifica- 
tion, and the status of proposed changes to the 
approved configuration and the implementation status 
of approved changes. 

12. CC NT50L SOF T WARE ; Common to a computer type and 
required to execute a computer program# but it doss 
not contain the specific application instructions, 
data or logic. 

13. DEFICIE NCY; 

a) D esi gn Deficiency; Any condition that limits or 
prevents the use of material for the purpose 
intended or required where the material meets all 
other specifications or contractual requirements. 
These deficiencies cannot be corrected except 
through a design change. 

Qual it 7 Defici e ncy ; Any deficiency (e.g. , 
physical, chemical, electrical, functional) noted 
in material which is attributable to noncomfor- 
mance to applicable specif ications, drawings, 
standards, or technical orders, or workmanship 
during manufacture, repair, modification, or 
maintenance. 
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An error in the 



c) Comp u ter Progra m Def icie ncy: 

statements cr instructions that make up a comcuter 
program used by an embedded computer system. The 
deficiency nay consist of syntax, logic, or ether 
discrepancies that cause the program to fail the 
intended function. 

14. 3WBEDDED COMP OIEB SYSTEM; A computer (or computers), 
equipment, documentation, and programs that are 
integral to a weapon system, subsystem, cr support 
system whose primary purpose is to control, sense, 
interpret, process, aid in, or direct operation of 
the larger system. 

15. FIRMWAR E : Software embedded in special media and 

cannet be readily modified under program contrcl; 
that is, "read only." It can be modified only by 
special processes which provide physical and/or elec- 
tronic access to the media. Examples are read only 
memory (ROM) , programmable read only memory (PROM) , 
electrically alterable read only memory (EAROM) , and 
erasable programmable read only memory (EPROM) . 

16. H A fi D W AP. E INTENSIV E: Those microprocessor applica- 

tions in which the function is fixed and application 
software/ firmware is not expected to change; or would 
require redevelopment of the application function 
itself if a change is necessary. 

17. I NTEGRA TION SOP PORT FAC ILITY; An engineering 

facility established to support weapon system 

embedded computer systems. It is made up of people, 

equipment, physical and environmental facilities, 
data, documentation, and procedures. Its uses may 
include the capability to simulate missions, evaluate 
computerized systems or subsystems, test modifica- 
tions, and integrate hardware, software and 
man-machine interfaces. It provides a capability for 
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base line and configuration management of software 
configured items. 

18. INTEBFACE: a region common to two or more elements, 

systems, projects, or programs, characterized by 
mutual physical, functional, and/or procedural prop- 
erties. 

19. MICRCC0 H PUT E5 ; A complete electronic computer on a 
single integrated circuit. 

20. M ICRCCO dPUTER BOARD : A small number of integrated 

circuits on a hoard to form a complete electronic 
computer . 

21. MICR CCO MPOTER CHI P S^: A small number of integrated 

circuits that together form a complete electronic 
computer . 

22. MICR OPROGRAM FIRMWA RE: Firmware at the micrcccde 

level; than is, ROM-based programs that identify rhe 
instruction set of a particular machine. 

23. MICR C PRO CSS S O fl; A single integrated circuit which 
determines and carries out the instruction architec- 
ture of a particular computer. 

24. MICROPROCESSOR FAMILY: A collection Of integrated 

circuits which includes microprocessors and the 
support products necessary for carrying out a wide 
range of system functions. 

25. O RGANIC SUPPORT: When this term is applied to weapon 

system computer resources, it represents the manage- 
ment and technical support at an AFLC family manned 
principally by government personnel. 

26. OPERATIO NAL SOFTWARE ; Generally, operational soft- 
ware which automatically performs or assists in the 
performance of a navigation or weapon system mission 
function. Includes Built-In-Test (BIT) logic used to 
evaluate the status of operational equipment and/or 
identify faults in equipment while in an installed 
configuration . 
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27. SOFTWAR E ; Th 2 instructions or procedures a compursr 
recognizes ("reads”) and then executes. It is '’sofr” 
in the sense that it is easily altered. A combina- 
tion of associated computer programs and computer 
data required to command the computer equipmenz to 
perform computational or control functions. 

28. SO FTWAR E INTB R SIV E; Those microprocessor applica- 
tions in which the function can vary and the 
application software/f irmware is subject to change. 

29. SUPPORT SOFT W ARE : Programs which aid or are neces- 

sary in the preparation of computer programs such as 
editors, compilers, assemblers, translators, etc. 
which may or may not exist "on-line”. 

30. TES T SOF TWA RE : Programs which contain the logic, 

stimuli identification, response evaluation, and 
instructions for the automatic conduct of tests. 
Programs used to analyze the data collected from the 
conduct of tests. 

31. VAL IDATION: As used herein, validation comprises 

those evaluation, integration, and test activities 
carried out at the system level to assure that the 
finally developed systems satisfies the mission 
requirements of the System Specification. 

32. VERIFICATIO N : As used herein, verification is the 

iterative process of determining whether the product 
of selected steps in the Cl or CPCI development 
process fulfills the requirements of each step, i. e. , 
review, audit, test, etc., ascertained through an 
appropriate "verification method"- test, demonstra- 
tion, inspection or analysis. 



89 



AEPEndix c 

ECP CLASSI?ICATION 

Each engineering change shall be assigned the appro- 
priate classification by the originator. Disagreements as 
to classification between intermediate government review 
activities and the originator may be appealed to the govern- 
ment procuring activity for decision. 

CLASS I ENGINEERING CHANGE: An engineering change shall 

be classified Class I when one or more of the factors listed 
below is affected: 

1. the function or allocated configuration identifica- 
tion 

2. The product configuration identification as contrac- 
tually specified, excluding referenced drawings, 
specifications, listing of computer program instruc- 
tions and actual data values 

NOTE: In the above definition of a Class I engineering 

change, the words "excluding referenced drawings, specifica- 
tions, listing of computer program instructions, and actual 
data values" shall net be interpreted to exclude these items 
prescribed directly in a contract to define contract line 
items. Other drawings, specifications, computer program 
instructions and actual data values, whether referenced in 
documents or listed cn associated lists are excluded from 
the above, but included in the below factors. 

3. Technical reguirements below contained in the Product 

Configuration Identification as contractually speci- 
fied, including referenced drawings and 

specifications: 

a) performance outside stated tolerance 
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b) r suability. 



or 



survivabiiiry 



aa intaiaability 
outsids stated tolerance 

c) weight, balance, moment of inertia 

d) interface characteristics 

4. Son-technical' contractual provisions 

a) fee 

b) incentives 

c) cost to the government 

d) schedules 

e) guarantees or deliveries 

5. Other factors 

a) government furnished equipment 

b) safety 

c) electromagnetic characteristics 

d) operational, test or maintenance computer programs 

e) compatibility with support equipment, trainers or 
training devices/equipment 

f) configuration to the extent that retrofit action 
would be taken 

g) delivered operation and maintenance manuals for 
which adequate change/revision funding is not or. 
existing contracts 

h) pre-set adjustments or schedules affecting oper- 
ating limits or performance to such extant as to 
require assignment of a new identification number 

i) interchangeability, suostitutability or replace- 
ability as applied to Cl's, and to all 
subassemblies and parts or repairable Cl's, 
excluding tha pieces and parts of non-repairable 
subassemblies. 

j) Sources of Cl's or repairable items at any level 
defined by source control drawings 

k) skills, manning, training, biomedical factors or 
human engineering design 
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Ad engiDeering changa xo a privaxeiy developed ixaa 
shall be classified Class I when it affects the ccnxracxu- 
ally specified form, fit or function of xhe item. When a 
greater degree of control is negotiated between the govern- 
ment and the contractor, effects on other factors may be 
added to the effects on form, fit or function factors which 
classify an engineering change as Class I. 

CLASS II ENGINEERING CHANGE: An engineering change 

shall be classified class II when it does not fall within 
the definition of a Class I engineering change. 

Examples of a Class II engineering change are; 

1. a change in documentation only 

2. a change in hardware which does not affect any factor 
listed under Class I engineering changes 
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4PPEHDIX D 

CLASS I ECP JOSTIFICATIOH CODES 

Cedes corresponding with the criteria for Class I engi- 
neering changes for necessary or beneficial engineering 
changes are defined in the following subparagraphs. If one 
or more cf these cedes is applicable to a Class I engi- 
neering change, the one which is the most descriptive or 
significant shall be assigned xo the EC?. If no code is 
pertinent, the ECP is not desired. 

1. CORRECTION OF DEFICIENCY (CODE D) : Code D shall be 

assigned to an engineering change which is reguired 
to eliminate a deficiency, unless a more descriptive 
separate code applies. Such separate codes are used 
tc identify deficiencies of the nature cf safety, 
interface or compatibility. 

2. SAFETY (CODE S) : Code S shall be assigned tc an 

engineering change for correction of a deficiency 
which is required primarly to eliminate a hazardous 
ccnditic n. 

3. INTERFACE (CODE B) : Code 3 shall be assigned to an 

engineering change for correction of a deficiency 
which will eliminate interference or incompatibility 
at the interface between configuration items. 

4. COMPATIBILITY (CODE C) : Code C shall be assigned to 

an engineering change for correction of a deficiency 
of the following characteristics: 

a) The need for the change has been discovered during 
the system or item functional checks or during 
installation and checkout and is necessary to make 
the system or item work, and 
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b) The crigina-tor in assigning nhs compatibility coda 
is declaring that the effort required to accom- 
plish the change is considered to be within the 
scope of his existing contract, and 

c) Contractual coverage completing the formal docu- 
mentation of the engineering change will not 
reflect an increase in contract price. 

5. OPERATIONAL OR LOGISTICS SUPPORT (CODE 0); Code 0 
shall be assigned to an engineering change which will 
make a significant effectiveness change in opera- 
tional or logistics support requirements, 

6. COST REDUCTION (CODE R) : Code R shall be assigned to 

an engineering change which will provide a net total 
cost savings to the Government, including not only 
all effects cn cost or price under the immediate 
contract but also the costs resulting from necessary 
associated changes in delivered items, logistic 
support and items produced by others. 

7. VALUE ENGINEERING (CODE V) : Code V shall be assigned 

to an engineering change which will effect a net life 
cycle cost reduction and which is submitted pursuant 
to the value engineering clause of the contract. 

3. PRODUCTION STOPPAGE (CODE P) ; Code P shall be 
assigned to an engineering change which is required 
to prevent slippage in an approved production sche- 
dule. This code applies when production to the 
current configuration identification either is 
impracticable or can not be accomplished without 
delay. 

9. RECORD ONLY (CODE A) : Code A shall be assigned to an 

engineering change which, because of impact cn the Cl 
or cn logistics support, is a Class I change, but 
owing to the contracting method, it is within the 
scope of the contract and should not be processed for 
formal change. 
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AP PEN DIX E 

CLASS I ENGINEEHING CHANGE PSIOHITIES 

A priority shall ba assigned to each Class I EC? based 
upon a selection from the following definitions. The 
priority will determine the relative speed at which the ECP 
is reviewed and evaluated, and at which the engineering 
change is ordered and implemented. The proposed priority is 
assigned by the originator and will stand unless the 
procuring activity has a valid reason for changing the 
processing rate. 

1. EMERGENCY: An emergency priority shall be assigned 

to an engineering change proposed for either of the 
following reasons: 

a) To affect a change in operational characteristics 
which, if not accomplished without delay, may 
seriously compromise the national security. 

b) To correct a hazardous condition which may result 
in fatal or serious injury to personnel or in- 
extensive damage or destruction of equipment. A 
hazardous condition usually will require with- 
drawing the item from service temporarily, or 
suspension of the item operation, or discontin- 
uance of further testing or development pending 
resolution of the condition. 

2. URGENT: An urgent priority shall be assigned to an 

engineering change proposed for any of the follcwing 
reasons : 

a) To affect a change in operational characteristics 
which, if not accomplished expeditiously, may 
seriously compromise the mission effectiveness of 
deployed equipment. 
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b) Tc cotrec- a po-anxially hazardous coaditio?., the 
uncorrsctsd existence of which could result in 
injury to personnel or damage to equipment. A 
potentially hazardous condition compromises safety 
and embodies risk, but within reasonable limits, 
permitting continued use of the effected equipment 
provided the operator has been informed of the 
hazard and appropriate precautions have been 
defined and distributed to the user. 

c) Tc meet significant contractual requirements 
(e.g., when lead time will necessitate slipping 
approved production, activation or construction 
schedules if the change were not incorporated) . 

d) Tc affect an interface change which, if delayed, 
would cause a schedule slippage or increase cost. 

e) Tc affect, through value engineering or other cost 
reduction efforts, net life cycle savings to the 
Government of a total or more than one hundred 
thousand dollars, where expedited processing of 
the change will be a major factor in realizing 
these lower costs. 

3. acUTINE: A routine priority shall l^e assigned to a 

proposed engineering change when emergency or urgent 
- is not applicable. 
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